On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > I think his point is why don't we clear currval() on DISCARD ALL? I > > can't think of a good reason we don't. > > Because we'd have to invent a new suboperation DISCARD SEQUENCES, > for one thing, in order to be consistent. I'd rather ask why it's > important that we should throw away such state. It doesn't seem to > me to be important enough to justify a new subcommand.
"consistency" is a philosophical thing. Practical reason for subcommands is possibility to have partial reset for special situations, pooling or otherwise. But such usage seems rather rare in real life. If the sequences are not worth subcommand, then let's not give them subcommand and just wait until someone comes with actual reason to have one. But currval() is quite noticeable thing that DISCARD ALL should clear. > Or, if you'd rather a more direct answer: wanting this sounds like > evidence of bad application design. Why is your app dependent on > getting failures from currval, and isn't there a better way to do it? It just does not sound like, but thats exactly the request - because DISCARD ALL leaves user-visible state around, it's hard to fix application that depends on broken assumptions. In fact, it was surprise to me that currval() works across transactions. My alternative proposal would be to get rid of such silly behaviour... -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers