Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
Date
Msg-id 27374.1176744959@sss.pgh.pa.us
Whole thread Raw
In response to Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch  (Zoltan Boszormenyi <zb@cybertec.at>)
Responses Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch  (Zoltan Boszormenyi <zb@cybertec.at>)
List pgsql-hackers
Zoltan Boszormenyi <zb@cybertec.at> writes:
> Apart from making the patch a bit smaller again, checking only
> for 'i' still allows multiple SERIALs in the same table but lets
> disallowing multiple GENERATED ALWAYS AS IDENTITY.
> Thinking a bit about it, is it desired to disallow multiple GENERATED
> ALWAYS AS IDENTITY fields? It's just a twisted SERIAL anyway.

I don't see the value of disallowing it.

> Also, DROP IDENTITY is equivalent with SET DEFAULT
> nextval('owned_sequence') iff the field has an OWNED
> sequence and it was GENERATED ALWAYS AS IDENTITY before.
> Considering that SERIAL is a macro, and SET/DROP DEFAULT is allowed
> on IDENTITY/GENERATED columns per Tom's request,
> should I keep this statement?

If it's not in the spec I don't see any strong reason to have it...

> Also, the current grammar is made to give a syntax error
> if you say "colname type GENERATED BY DEFAULT AS ( expr )".
> But it makes the grammar unbalanced, and gives me:
> bison -y -d  gram.y
> conflicts: 2 shift/reduce

You'll have to fix that.  Usually you can get around it by making the
grammar a bit more verbose --- if you were trying to avoid duplication
by means of optional productions, don't do that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martin Langhoff
Date:
Subject: Hacking on PostgreSQL via GIT
Next
From: Aidan Van Dyk
Date:
Subject: Re: Hacking on PostgreSQL via GIT