6 ms·
Something that doesn't appear to be mentioned in here that bit me recently is that views follow a table through renames. Ended up having views that were subtly
by ziml77 5y ago
Something that doesn't appear to be mentioned in here that bit me recently is that views follow a table through renames. Ended up having views that were subtly broken because they were pointing to the tables that I had renamed to have an _old suffix instead of the newly created ones I had expected them to point to.
- giraffe_lady 5y agoPostgres is one of the very few technologies that I think is like, actually very good. But it is full of stuff like this. If I had thought about it for a minute it's possible I could have predicted this behavior, but maybe not!
- takeda 5y agoMaybe there are issues, but this behavior is something I would personally expect and I believe this is the right way. I wouldn't want database to lookup the table/column id every time an extra lookup of the name is performed.
- hashimotonomora 5y agoAll objects update their reference after a renaming. If you rename a column, foreign keys referencing that column have the name updated.
- giraffe_lady 5y agoI commented elsewhere that the view renaming thing was surprising to me, but when you put it like this it makes sense. The view references the oid or whatever, some internal representation I try to pretend doesn't exist. It's kind of surprising in some cases when I haven't seen it before (like views) but is consistent and the alternative would be a lot harder to work with.
- radiowave 5y agoOff the top of my head, the exception to this is functions (i.e. that you declare inside Postgres), because the function body is really just a piece of text, in any of a bunch of different languages. So if you have a function which refers to specific database objects that are being renamed, you'll also need to update the function definition with the new names.
- uhoh-itsmaciek 5y agoNote that SQL-standard bodies are supported as of 14 [1]: Allow SQL-language functions and procedures to use SQL-standard function bodies (Peter Eisentraut) Previously only string-literal function bodies were supported. When writing a function or procedure in SQL-standard syntax, the body is parsed immediately and stored as a parse tree. This allows better tracking of function dependencies, and can have security benefits. [1]: https://www.postgresql.org/docs/14/release-14.html https://www.postgresql.org/docs/14/release-14.html
- giraffe_lady 5y agocan you declare and modify string literal functions inside sql standard functions? if so that's form interpretation right, you could build a powerful lisp-style macro system that way I think.
- radiowave 5y agoAh, that's good news. Thanks.
- ziml77 5y agoIt definitely does make sense and it probably what most people expect if they've never worked with a database before. But coming from my experience with other databases (primarily MS SQL Server) it's a surprising difference. On me for not testing better, but it was some quick and dirty work in a quick and dirty environment that doesn't even have a dev instance.
- teej 5y agoRedshift added a feature to create views “WITH NO SCHEMA BINDING” to solve this but the Postgres team hasn’t added an equivalent yet.
- djrobstep 5y agoThis is a very good example of why you should be using a schema diff/comparison tool. Run your rename on a copy of your production schema, then run a diff tool to see what's actually changed - in this case it would show a view definition had changed and even autogenerate the replace statement you would need to add to fix the script.
- Ozzie_osman 5y agoWhat specific tools would you recommend for schema diffs?
- rockwotj 5y agohttps://atlasgo.io/ https://atlasgo.io/ or https://github.com/djrobstep/migra https://github.com/djrobstep/migra