Re: BUG #4684: lastval in function

Andreas <postgresql(at)elbrief(dot)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/>