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
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
- ext
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.
---
Zo
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 ready?
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 th
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.
---
Zo
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
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
t
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 behavi
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 tha
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
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
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 (anothe
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 han
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 correct
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
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 sta
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
> t
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 bet
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
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?
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?
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
where
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 GENE
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 b
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 I
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 incl
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
exam
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
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
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
i
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 ...".
> >
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
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:
34 matches
Mail list logo
