Neil Conway <neilc@samurai.com> writes:
> Per my earlier mail, the other debatable behavior is whether
> lastval() should be defined if the sequence it would be returning the
> currval() for has been subsequently dropped. I'm inclined to not return
> an error here to simplify the implementation, but I'm open to objections.
I agree with that --- consider that you couldn't actually promise that
the sequence hadn't been dropped by the time the answer is returned,
anyway, unless you take out a lock on the sequence first. Which doesn't
seem like a behavior that is wanted here.
>> Another question is why should setval affect the result? I don't
>> see the use-case for that offhand.
> I'm not militant about it, but having setval() affect the result means
> lastval() is more consistent with currval().
That is a point; on the other side consider that the simpler definition
is better. Without a pretty strong reason to include setval in the list
of things that affect lastval, I'd leave it out. We just agreed above
that DROP SEQUENCE won't affect lastval, so you can hardly argue that
lastval will track currval's behavior exactly ...
regards, tom lane