Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-17 Thread Zoltan Boszormenyi
Tom Lane írta: Andrew Dunstan [EMAIL PROTECTED] writes: Zoltan Boszormenyi wrote: Thanks. This idea solved one of the two shift/reduce conflicts. But the other one can only be solved if I put GENERATED into the reserved_keyword set. But the standard spec says it's unreserved. Now what

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-17 Thread Zoltan Boszormenyi
Zoltan Boszormenyi írta: Tom Lane írta: Andrew Dunstan [EMAIL PROTECTED] writes: Zoltan Boszormenyi wrote: Thanks. This idea solved one of the two shift/reduce conflicts. But the other one can only be solved if I put GENERATED into the reserved_keyword set. But the standard spec says

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-17 Thread Alvaro Herrera
Andrew Dunstan wrote: Tom Lane wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of lookahead than we have to tell if the default expression is 5! or 5!GENERATED There are

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-17 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: BTW I just noticed this bug in the comment above a_expr: * Note that '(' a_expr ')' is a b_expr, so an unrestricted expression can * always be used by surrounding it with parens. It is wrong because it's not a b_expr, but a c_expr. Well, it's right

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-17 Thread Andrew Dunstan
Tom Lane wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of lookahead than we have to tell if the default expression is 5! or 5!GENERATED There are basically two ways to fix this: 1.

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-16 Thread Zoltan Boszormenyi
Zoltan Boszormenyi írta: Andrew Dunstan írta: Florian G. Pflug wrote: bison -y -d gram.y conflicts: 2 shift/reduce I'ts been quite a time since I last used bison, but as far as I remember, you can tell it to write a rather details log about it's analysis of the grammar. That log should

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-16 Thread Andrew Dunstan
Zoltan Boszormenyi wrote: You can almost always get rid of shift/reduce conflicts by unwinding some of the productions - resist the temptation to factor the grammar. The effect of this is to eliminate places where the parser has to decide between shifting and reducing. (This is why, for

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-16 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Zoltan Boszormenyi wrote: Thanks. This idea solved one of the two shift/reduce conflicts. But the other one can only be solved if I put GENERATED into the reserved_keyword set. But the standard spec says it's unreserved. Now what should I do with it?

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-14 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: So, I should allow DROP DEFAULT, implement SET DEFAULT GENERATED ALWAYS AS and modify the catalog so the GENERATED property is part of pg_attrdef. Sounds good. Finally here it is. What about IDENTITY? Should it also be

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-14 Thread Zoltan Boszormenyi
Zoltan Boszormenyi írta: Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: So, I should allow DROP DEFAULT, implement SET DEFAULT GENERATED ALWAYS AS and modify the catalog so the GENERATED property is part of pg_attrdef. Sounds good. Finally here it is. What about

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: [ IDENTITY/GENERATED patch ] I got around to reviewing this today. Thanks for the review. Sorry for the bit late reply, I was ill and then occupied with some other work. - unique index checks are done in two steps to

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Andrew Dunstan
Zoltan Boszormenyi wrote: Tom Lane írta: - unique index checks are done in two steps to avoid inflating the sequence if a unique index check is failed that doesn't reference the IDENTITY column This is just not acceptable --- there is nothing in the standard that requires such

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Andrew Dunstan írta: Zoltan Boszormenyi wrote: Tom Lane írta: - unique index checks are done in two steps to avoid inflating the sequence if a unique index check is failed that doesn't reference the IDENTITY column This is just not acceptable --- there is nothing in the standard

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: The idea wouldn't have considered to cross my mind if Tom didn't mention the action-at-a-distance behaviour. AFAIR, that remark had to do with NEXT VALUE FOR, which SQL2003 defines in a very weird way (it's not equivalent to nextval() as one would

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: The idea wouldn't have considered to cross my mind if Tom didn't mention the action-at-a-distance behaviour. AFAIR, that remark had to do with NEXT VALUE FOR, which SQL2003 defines in a very weird way (it's not equivalent to

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Here's the new version with the modifications you requested. I see another problem with this patch: the code added to ATExecDropColumn is a crude hack. It doesn't work anyway since this is not the only possible way for columns to be dropped (another

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
I wrote: I see another problem with this patch: the code added to ATExecDropColumn is a crude hack. It doesn't work anyway since this is not the only possible way for columns to be dropped (another one that comes to mind immediately is DROP TYPE ... CASCADE). The only correct way to handle

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: I wrote: I see another problem with this patch: the code added to ATExecDropColumn is a crude hack. It doesn't work anyway since this is not the only possible way for columns to be dropped (another one that comes to mind immediately is DROP TYPE ... CASCADE). The only

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Before you get too excited about making generated columns disappear automatically in all these cases, consider that dropping a column is not something to be done lightly --- it might contain irreplaceable data. The standard says that the GENERATED

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Before you get too excited about making generated columns disappear automatically in all these cases, consider that dropping a column is not something to be done lightly --- it might contain irreplaceable data. The

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: I have two questions about the dependency system. 1. Is there a built-in defense to avoid circular dependencies? It doesn't have a problem with them, if that's what you mean. 2. If I register dependencies between column, is there a way to

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: I have two questions about the dependency system. 1. Is there a built-in defense to avoid circular dependencies? It doesn't have a problem with them, if that's what you mean. 2. If I register dependencies

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: So, I should allow DROP DEFAULT, implement SET DEFAULT GENERATED ALWAYS AS and modify the catalog so the GENERATED property is part of pg_attrdef. Sounds good. What about IDENTITY? Should it also be part of pg_attrdef? There are two ways to

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: So, I should allow DROP DEFAULT, implement SET DEFAULT GENERATED ALWAYS AS and modify the catalog so the GENERATED property is part of pg_attrdef. Sounds good. What about IDENTITY? Should it also be part of pg_attrdef?

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Tom Lane írta: The latter would treat GENERATED BY DEFAULT AS IDENTITY the same as SERIAL. Is there any good reason to distinguish the two? Yes. Plain SERIALs can be updated with given values whereas IDENTITY columns cannot. Really? How is

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Zoltan Boszormenyi
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Tom Lane írta: The latter would treat GENERATED BY DEFAULT AS IDENTITY the same as SERIAL. Is there any good reason to distinguish the two? Yes. Plain SERIALs can be updated with given values

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-04-04 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Yes. Plain SERIALs can be updated with given values whereas IDENTITY columns cannot. Really? How is pg_dump going to deal with that? It emits ALTER TABLE ... SET GENERATED AS IDENTITY

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-03-26 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: [ IDENTITY/GENERATED patch ] I got around to reviewing this today. - unique index checks are done in two steps to avoid inflating the sequence if a unique index check is failed that doesn't reference the IDENTITY column This is just not

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-03-03 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. ---

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-03-02 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. ---

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-03-02 Thread Zoltan Boszormenyi
Hi! Thanks. However, in the meantime I made some changes so the IDENTITY column only advances its sequence if it fails its CHECK constraints or UNIQUE indexes. I still have some work with expression indexes. Should I post an incremental patch against this version or a full patch when it's

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-03-02 Thread Bruce Momjian
Zoltan Boszormenyi wrote: Hi! Thanks. However, in the meantime I made some changes so the IDENTITY column only advances its sequence if it fails its CHECK constraints or UNIQUE indexes. I still have some work with expression indexes. Should I post an incremental patch against this

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-02-28 Thread Zoltan Boszormenyi
Hi, I think now this is really the final version. Changes in this version is: - when dropping a column that's referenced by a GENERATED column, the GENERATED column has to be also dropped. It's required by SQL:2003. - COPY table FROM works correctly with IDENTITY and GENERATED columns -

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

2007-02-27 Thread Zoltan Boszormenyi
Resending compressed, it seems pgsql-patches doesn't let me post so large patches. Zoltan Boszormenyi írta: Hi, I have finished my GENERATED/IDENTITY patch and now it does everything I wanted it to do. Changes from the previous version: - GENERATED columns work now - extended testcase to test