Re: identity columns

On Mon, Apr 24, 2017 at 10:03 AM, Vitaly Burovoy
<vitaly(dot)burovoy(at)gmail(dot)com> wrote:
> On 4/23/17, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
>> <vitaly(dot)burovoy(at)gmail(dot)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