On Fri, Apr 19, 2013 at 10:50 AM, Robert Haas <robertmh...@gmail.com> wrote:
> > [...] > > So it seems to me that we pretty much already made a decision that the > controlling definition of DISCARD ALL is that, as the fine manual says > "DISCARD ALL resets a session to its original state". Whatever > decision we make now ought to be consistent with that. > > IOW, I don't care whether we introduce a new subcommand or not. But I > *do* think that that we ought to make our best effort to have DISCARD > ALL clear everything that smells like session-local state. Random > incompatibilities between what you see when running under a connection > pooler and what you see when connecting the DB directly are *bad*, > regardless of whether a well-designed application should be relying on > those particular things or not. The whole point of having a > transparent connection pooler is that it's supposed to be transparent > to the application. > > +1 The attached wip patch do that and introduce a subcommand 'SEQUENCES', but if we decide to don't add a new subcommand to DISCARD, then its easier to modify the patch. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello
discard_sequences.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
