Re: [PATCH] Alter or rename enum value - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCH] Alter or rename enum value
Date
Msg-id 9dd58b5f-0447-54fe-02f4-afb62fd7c3c8@dunslane.net
Whole thread Raw
In response to Re: [PATCH] Alter or rename enum value  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Alter or rename enum value  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 09/06/2016 02:30 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Sep 5, 2016 at 11:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> ... And again, it's
>>> hard to get excited about having these options for RENAME VALUE when no
>>> one has felt a need for them yet in RENAME COLUMN.  I'm especially dubious
>>> about IF NOT EXISTS against the destination name, considering that there
>>> isn't *any* variant of RENAME that has an equivalent of that.  If it's
>>> really useful, why hasn't that happened?
>> Because Tom Lane keeps voting against every patch to expand IF [ NOT ]
>> EXISTS into a new area?  :-)
> Well, I'm on record as not liking the squishy semantics of CREATE IF NOT
> EXISTS, and you could certainly make the same argument against RENAME IF
> NOT EXISTS: you don't really know what state you will have after the
> command executes.  But that wasn't the point I was trying to make here.
>
>> We do have ALTER TABLE [ IF EXISTS ] .. ADD COLUMN [ IF NOT EXISTS ],
>> so if somebody wanted the [ IF NOT EXISTS ] clause to also apply to
>> the RENAME COLUMN case, they'd have a good argument for adding it.
> If someone wanted to propose adding IF NOT EXISTS to our rename
> commands across-the-board, that would be a sensible feature to discuss.
> What I'm objecting to is this one niche-case command getting out in
> front of far-more-widely-used commands in terms of having such features.
> I think the fact that we don't already have it in other rename commands
> is pretty strong evidence that this is a made-up feature rather than
> something with actual field demand.  I'm also concerned about adding it
> in just one place like this; we might find ourselves boxed in in terms of
> hitting syntax conflicts when we try to duplicate the feature elsewhere,
> if we haven't done the legwork to add it to all variants of RENAME at
> the same time.
>
>     



Are we also going to have an exists test for the original thing being 
renamed? Exists tests on renames do strike me as somewhat cumbersome, to 
say the least.

cheers

andrew




pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] COPY vs \copy HINT