Zoltan Boszormenyi <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to