From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: next value expression |
Date: | 2002-11-27 18:46:10 |
Message-ID: | 20702.1038422770@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> There's already a need to reform the way in which the next value of a
> sequence is produced (nextval() makes it difficult to get the dependancy
> information right); would it be a good idea to change it to be
> completely SQL compatible at the same time?
What do you consider "completely SQL compatible" here? In particular,
what is a "statement"? My initial reaction to this part of the SQL
draft is that it's broken. Consider plpgsql functions invoked within
an interactive statement --- if they invoke nextval() should it fail to
increment across repeated attempts? Does your answer change if the
functions are invoked as triggers, rather than directly in the text of
the statement? How about queries inserted by rule rewriting; are those
separate statements for this purpose? In any of these contexts I think
you can construct examples that would favor either answer.
ISTM that we will have all the same issues with this that we had with
the question of when "now()" should increment...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Langille | 2002-11-27 19:16:33 | Re: contrib/ltree patches |
Previous Message | Bruce Momjian | 2002-11-27 18:36:31 | Re: [INTERFACES] ANNOUNCE: DBD::Pg 1.20 |