On Tue, Apr 16, 2013 at 05:09:19PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@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
