Neil Conway <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org