Re: [PATCH] rename column if exists

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, David Oksman <oksman(dot)dav(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] rename column if exists
Date: 2021-11-05 15:00:49
Message-ID: CAKFQuwZCG8sJZ-X78n1qmoE+EP7M-mjNfFvSop-VUiOcQTQRdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, November 5, 2021, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I'd be more willing to overlook that if a clear use-case had been
> given, but AFAICS no concrete case has been offered.
>
>
The use case is the exact same one for all of these - indempotence,
especially in the face of being able to run migration scripts starting at a
point in the past and still having the final outcome be the same (or error
if there is a fundamental conflict in the history). It’s the same argument
used for why our current implementation of create [type] if not exists is
broken in how it deals with schemas.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-11-05 15:04:40 Re: should we enable log_checkpoints out of the box?
Previous Message Mark Dilger 2021-11-05 14:58:15 Re: pg14 psql broke \d datname.nspname.relname