"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Friday, November 5, 2021, Daniel Gustafsson <daniel@yesql.se> wrote:
>> I know that, I'm just not convinced that it's a feature (in the case at
>> hand)
> I don’t see how this one should be expected to meet a higher bar than drop
> table or other existing commands. I get why in the nearby discussion
> create role if not exists is treated differently based upon its unique
> security concerns. Does column renaming have a hidden concern I’m not
> thinking of?
IMV, the best forms of these options are the ones that produce a known
end state of the object. DROP IF EXISTS meets that test: upon successful
completion, the object doesn't exist. CREATE OR REPLACE meets that test:
upon successful completion, the object exists and has exactly the
properties stated in the command. CREATE IF NOT EXISTS fails that test,
because while you know that the object will exist afterwards, you've got
next to no information about its properties. We've put up with C.I.N.E.
semantics in some limited cases like CREATE TABLE, where C.O.R.
semantics would be too drastic; but IMO it's generally best avoided.
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'd be more willing to overlook that if a clear use-case had been
given, but AFAICS no concrete case has been offered.
regards, tom lane
