I wrote:
> I believe this exact issue was debated when ADD COLUMN IF NOT EXISTS
> was added, and the camp that wanted it thought this behavior was fine.
After a bit of digging in the archives, I failed to find any evidence
that the point was considered when the ADD COLUMN IF NOT EXISTS patch
went in, though there have certainly been related threads in the dim
past, which basically led to the conclusion that you don't get to have
much certainty about what state IF NOT EXISTS leaves behind, and those
who think it's a good feature think that's OK. (I am not among them.)
The thing I was half-remembering was probably this bug report about
the unique-constraint aspect of the same problem:
https://www.postgresql.org/message-id/flat/152509815280.19803.16118194452213577808%40wrigleys.postgresql.org
wherein it was argued that if the IF NOT EXISTS fires, it should prevent
all side-effects of the ADD COLUMN clause it's attached to, whether or not
any of the subsidiary objects exist (in some form) already. If you buy
that theory then there's a sketch for a fix there. Nobody's done anything
about it AFAIK.
regards, tom lane
