Andreas <postgre...@elbrief.de> writes: > Heikki Linnakangas schrieb: >> andreas wrote: >>> if nextval is used inside a function in a insertstatement, you get always >>> the value from inside the last function. but i expected, that lastval() >>> deliver the value from the insertstatement. i think, this should >>> clearify in >>> the documentation, or better fixed that the nextval from an >>> insertstatement >>> is called after the functioncalls. >> >> Well, others might expect the opposite, like existing >> applications. Want to suggest wording for the documentation? > > Yes, existing applications might be involved. But i think, this is a > very rare situation. But if someone use an insertstatement with a > functioncall, but the function do NOT use nextval, and he use lastval to > estimate the last inserted value he has no problems. But if then someone > change the function so the function use nextval then the application > crashes. So i think it is much more better to change the behavior, > because this is what i expect. And i think, this is what others > expect too.
Someone recently reported this issue as a possible bug in Slony-I; they had written their application to use lastval() to capture sequence values, and then, when they introduced replication, they started capturing values of a sequence Slony-I uses to control *its* operations. You'd experience the same problem with any similar sort of "after" trigger that was added to do logging; any kind of logging system that uses sequences is liable to break usage of lastval(). This actually feels like it's a global versus dynamic/lexical scope problem <http://en.wikipedia.org/wiki/Scope_(programming)>. PostgreSQL is capturing *all* the sequence updates for the connection, where the application would apparently prefer to only see those that it *wants* to see. I'm not sure whether lexical or dynamic scope better reflect what might be desired. However, the notion of there being some kind of more-local scope is the big deal, something which PostgreSQL does not support. I'm not sure I'd *want* to have a more-sophisticated scoping mechanism for this. -- output = reverse("moc.enworbbc" "@" "enworbbc") http://cbbrowne.com/info/nonrdbms.html Rules of the Evil Overlord #177. "If a scientist with a beautiful and unmarried daughter refuses to work for me, I will not hold her hostage. Instead, I will offer to pay for her future wedding and her children's college tuition." <http://www.eviloverlord.com/> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
