On Fri, Jun 01, 2001 at 06:35:16PM -0400, Bruce Momjian wrote:
> > On Fri, Jun 01, 2001 at 04:18:54PM -0400, Bruce Momjian wrote:
> > >
> > > Care to add RESET ALL?
> >
> > What exactly should it do? We have:
> >
> > 1) Compiled in default
> > 2) postgres.conf / command line provided
> > 3) through SET modified
> >
> > I guess it should reset to 2). But is it possible to differ
> > 2) and 3) values?
> >
> > Or should it reset only some subset of vars (eg currenlty
> > variable.c special-cased?) What variables should belog to
> > that subset?
>
> Good question and this brings up issues with SHOW. Let's look at:
>
> SET ALL
> SHOW ALL
> RESET ALL
>
> The first makes no sense. The third is needed for persistent
> connections. Should RESET ALL also rollback any open transaction? If
> not, we have to keep our 'BEGIN;COMMIT;' hack in PHP to reset the
> transaction state. Do we eat an XID when we do that?
>
> If we have SHOW ALL show things that are not SET-able, is it clear what
> RESET ALL does? Can I recommend SHOW ALL output two groups, one
> SET-able, and the rest non-SET-able. When I say SET-able, I mean
> set-able by SET, not postgresql.conf.
As I understand Tom, all vars should go through GUC and some of
the current .conf vars will be SET-able. So RESET ALL would
be quite weird.
How about command 'RESET;' that resets some fixed vars so you
get some quaranteed sane state on general SQL level and leaves
the really magic vars alone? Eg.
1) rolls TX back, so you are not in any TX
2) resets TRANSACTION ISOLATION LEVEL
What else?
--
marko
