On Mon, Apr 24, 2017 at 10:03 AM, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 4/23/17, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy >> <vitaly.buro...@gmail.com> wrote: >> 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. > > I thought exactly that way, but Peter gave an explanation[1]. > I had to search a different way because no one joined to the > discussion at that time. > One of reasons from Peter was to make "SET GENERATED" follow the > standard (i.e. raise an error). > I asked whether "IF NOT EXISTS" works for him instead of "ADD GENERATED". > The answer[2] was "It could be done", but "it is very difficult to implement". > > So I wonder why the adjustment patch is not wished for being committed.
Same line of thoughts here, as far as I understand, ADD GENERATED and SET GENERATED have a lot in common, SET GENERATED follows the SQL spec, and not ADD GENERATED, so I don't have a good reason to not simplify the interface by keeping SET GENERATED and dropping ADD. This will be less confusing to users. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers