Re: [GENERAL] currval and DISCARD ALL

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Nigel Heron <nigel(at)psycode(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] currval and DISCARD ALL
Date: 2013-04-17 21:33:56
Message-ID: 20130417213356.GA27481@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-04-17 22:17:33 Re: [GENERAL] currval and DISCARD ALL
Previous Message Jeff Janes 2013-04-17 21:07:23 Re: Most efficient way to insert without duplicates

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-04-17 21:36:38 Re: Enabling Checksums
Previous Message Peter Eisentraut 2013-04-17 21:16:14 Re: event trigger API documentation?