On Fri, Nov 5, 2021 at 10:40 AM Tom Lane <tgl@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