On Fri, Nov 5, 2021 at 10:40 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > In this framework, RENAME IF EXISTS is in sort of a weird place. > You'd know that afterwards there is no longer any column with the > source name. But you are not entitled to draw any conclusions > about whether a column exists with the target name, nor what its > properties are. So that makes me feel like the semantics are more > on the poorly-defined than well-defined side of the fence.
I have mixed feelings about this proposal. As you may recall, I was a big fan of CREATE IF NOT EXISTS because it's a super-useful thing in DDL upgrade scripts. You have an application and every time you deploy it you CREATE IF NOT EXISTS all the tables that are supposed to be there. As long as the application is careful not to modify any table definitions, and nothing else is changing the database, this works great. You can add functionality by adding new tables, so the schema can be upgraded before the app. Life is good. Making renaming work in the same kind of context is harder. You're definitely going to have to upgrade the application and the schema in lock step, unless the application is smart enough to work with the column having either name. You're also going to end up with some trouble if you ever reuse a column name, because then the next time you run the script it might rename the successor of the original column by that name rather than the column you intended to rename. So it seems more finnicky to use. But I'm also not sure that it's useless. People don't usually ask for a feature unless they have a use in mind for it. Also, adding an option to skip failures when the object is missing is a popular kind of thing. The backend is full of functions that have a missingOK or noError flag, for example. Maybe the fact that I don't quite see how to use this effectively is just lack of imagination on my part.... -- Robert Haas EDB: http://www.enterprisedb.com
