Richard Huxton wrote:
sad wrote:
A. Kretschmer wrote:
is it expected that the currval() changes its value between calls
within one statement ?
Conclusion, don't call nextval() within a TRIGGER, and insert either
nextval() for the column or omit this column.
I only note that i still want to discuss the titled problem or to be
given an exact pointer to documentation regarding the currval() behavior
in the described situation, that i had.
Well, the page in the docs isn't hard to find -
http://www.postgresql.org/docs/8.2/static/functions-sequence.html
But surely it works exactly as you would expect it to.
nextval(S) advances the sequence and returns the new value
currval(S) returns the current value of sequence S, which is whatever
the previous call to nextval(S) returned. In the even you haven't called
nextval(S) then it is undefined.
Then this is the question on the execution order of the statement
INSERT...SELECT...
What do you think should happen?
I had expected all the currval() calls to be called before all the
triggers fired.
---------------------------(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
match
