Re: [HACKERS] identity columns - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] identity columns
Date
Msg-id 83f5d264-6d4a-01e0-a496-fcca7933c18b@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] identity columns  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] identity columns
List pgsql-hackers
On 4/23/17 16:58, Robert Haas wrote:
> I agree that ADD is a little odd here, but it doesn't seem terrible.
> But why do we need it?  Instead of:
> 
> ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
> SET GENERATED { ALWAYS | BY DEFAULT }
> DROP IDENTITY [ IF EXISTS ]
> 
> Why not just:
> 
> SET GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
> DROP IDENTITY [ IF EXISTS ]
> 
> Surely the ALTER TABLE command can tell whether the column is already
> GENERATED, so the first form could make it generated if it's not and
> adjust the ALWAYS/BY DEFAULT property if it is.

Note that DROP IDENTITY is a non-idempotent command (i.e., it errors if
the thing has already been dropped), per SQL standard, which is why we
have IF EXISTS there.  So it would be weird if the corresponding
creation command would be idempotent (i.e., it did not care whether the
thing is already there).

Also, if we tried to merge the ADD and SET cases, the syntax would come
out weird.  The creation syntax is

CREATE TABLE t1 (c1 int GENERATED ALWAYS AS IDENTITY);

The syntax to change an existing column is

ALTER TABLE t1 ALTER COLUMN c1 SET GENERATED ALWAYS;

But we can't just make the "AS IDENTITY" optional, because that same
syntax is also used by the "generated columns" feature.

So we could make up new syntax

ALTER TABLE t1 ALTER COLUMN c1 SET GENERATED ALWAYS AS IDENTITY;

and let that be set-or-add, but then the argument for staying within the
SQL standard goes out the window.

Finally, I had mentioned that earlier in this thread, the behavior of
the sequence options differs depending on whether the sequence already
exists.  So if you wrote

ALTER TABLE t1 ALTER COLUMN c1 SET GENERATED ALWAYS AS IDENTITY (START 2);

and the sequence does not exist, you get a new sequence with START 2 and
all default values otherwise.  If the sequence already exists, you keep
the sequence and just change the start value.  So that's not truly
idempotent either.

So I think altogether it is much clearer and more consistent to have
separate verbs for create/change/remove.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Unportable implementation of background worker start
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly