From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Vitaly Burovoy <vitaly.burovoy@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: identity columns
Date: Tue, 21 Mar 2017 21:04:33 -0400
Message-ID: <ec772da8-3443-b39d-e25e-138ef01a71c1@2ndquadrant.com> (raw)
In-Reply-To: <CAKOSWNnMp0sKZzcX0zSKJOTSb1Fas02+xTW=kvGMu2NhRiOAbg@mail.gmail.com>
References: <6adbacbf-73bc-dd1a-2033-63409180fd18@2ndquadrant.com>
<CAKOSWNk3Ug6CV5RBPhF1UCiaR32ZTxdtf-iZ+uv6C3rP6cN8QA@mail.gmail.com>
<CAKOSWNkKUAb1qwubq+MhxbEyT0ewM2NYsXKUskxheg_dUWnWPw@mail.gmail.com>
<4ef801f2-64ce-1a58-277d-d9389ae7770d@2ndquadrant.com>
<e287f723-d095-0d24-483a-3b7e3611c3e9@2ndquadrant.com>
<CAKOSWNmsci7jZzpoqWAH_QcVjQzwOMf04o91Jf5WVTkHbDMy2w@mail.gmail.com>
<1cf308b6-4f5c-05ba-cc74-0a7121603fcf@2ndquadrant.com>
<CAKOSWNmKbthEdV0m1J=V7r6nDyPk8diKwHW93jYbB+wnXd-c1A@mail.gmail.com>
<ed41b243-63b2-f287-e7b0-8b2ac7266d66@2ndquadrant.com>
<CAKOSWNnMp0sKZzcX0zSKJOTSb1Fas02+xTW=kvGMu2NhRiOAbg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 3/21/17 16:11, Vitaly Burovoy wrote:
> I've just checked and still get an error about a type, not about
> absence of a column:
> test=# CREATE TABLE itest3 (a int generated by default as identity, b text);
> CREATE TABLE
> test=# ALTER TABLE itest3 ALTER COLUMN o ADD GENERATED ALWAYS AS IDENTITY;
> ERROR: identity column type must be smallint, integer, or bigint
OK, I have a fix.
> My argument is consistency.
> Since IDENTITY is a property of a column (similar to DEFAULT, NOT
> NULL, attributes, STORAGE, etc.), it follows a different rule: it is
> either set or not set. If it did not set before, the "SET" DDL "adds"
> it, if that property already present, the DDL replaces it.
> There is no "ADD" clause in DDLs like "...ALTER table ALTER column..."
> (only "SET", "RESET" and "DROP")[2].
> Your patch introduces the single DDL version with "...ALTER column
> ADD..." for a property.
But it creates a sequence, so it creates state. So mistakes could
easily be masked. With my patch, if you do ADD twice, you get an error.
With your proposal, you'd have to use SET, and you could overwrite
existing sequence state without realizing it.
>> It does change the type, but changing the type doesn't change the
>> limits. That is a property of how ALTER SEQUENCE works, which was
>> separately discussed.
>
> Are you about the thread[1]? If so, I'd say the current behavior is not good.
> I sent an example with users' bad experience who will know nothing
> about sequences (because they'll deal with identity columns).
> Would it be better to change bounds of a sequence if they match the
> bounds of an old type (to the bounds of a new type)?
That's an idea, but that's for a separate patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, vitaly.burovoy@gmail.com
Subject: Re: identity columns
In-Reply-To: <ec772da8-3443-b39d-e25e-138ef01a71c1@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox