Re: [WIP] ALTER COLUMN IF EXISTS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [WIP] ALTER COLUMN IF EXISTS
Date
Msg-id 903090.1648773031@sss.pgh.pa.us
Whole thread Raw
In response to Re: [WIP] ALTER COLUMN IF EXISTS  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [WIP] ALTER COLUMN IF EXISTS  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, Mar 31, 2022 at 4:39 PM Bradley Ayers <bradley.ayers@gmail.com>
> wrote:
>> I'm interested in adding more ergonomics to DDL commands, in
>> particular supporting IF EXISTS for ALTER TABLE … ALTER COLUMN, so
>> that if a column doesn't exist the command is skipped.

> At present the project seems to largely consider the IF EXISTS/IF NOT
> EXISTS features to have been largely a mistake and while removing it is not
> going to happen the desire to change or extend it is not strong.

That might be an overstatement.  There's definitely a camp that
doesn't like CREATE IF NOT EXISTS, precisely on the grounds that it's
not idempotent --- success of the command tells you very little about
the state of the object, beyond the fact that some object of that name
now exists.  (DROP IF EXISTS, by comparison, *is* idempotent: success
guarantees that the object now does not exist.  CREATE OR REPLACE
is also idempotent, or at least much closer than IF NOT EXISTS.)
It's not entirely clear to me whether ALTER IF EXISTS could escape any
of that concern, but offhand it seems like it's close to the CREATE
problem.  I do kind of wonder what the use-case for it is, anyway.

One thing to keep in mind is that unlike some other DBMSes, you
can script pretty much any conditional DDL you want in Postgres.
This considerably reduces the pressure to provide conditionalization
built right into the DDL commands.  As a result, we (or at least I)
prefer to offer only the most clearly useful, best-defined cases
as built-in DDL features.  So there's definitely a hurdle that
an ALTER IF EXISTS patch would have to clear before having a chance
of being accepted.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: unlogged sequences
Next
From: Robert Haas
Date:
Subject: Re: should vacuum's first heap pass be read-only?