Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch
От | Tom Lane |
---|---|
Тема | Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch |
Дата | |
Msg-id | 27374.1176744959@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch (Zoltan Boszormenyi <zb@cybertec.at>) |
Ответы |
Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED
patch
|
Список | 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 по дате отправления: