Re: Updating psql for features of new FE/BE protocol

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Arguile <arguile(at)lucentstudios(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updating psql for features of new FE/BE protocol
Date: 2003-07-20 00:31:22
Message-ID: 200307200031.h6K0VNf29522@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Do we have any way of seeing all the predefined psql \set setting?

Right now if you do \set, you see the settings for that client, but you
don't see a list of setting the psql understands, like autocommit. You
can only see those in the psql manual.

On the server side, we have SHOW ALL which shows all setting. Of
course, \set works more like environment variables, so maybe it makes
sense not to have a way to display the powerful ones, but it would be
convenient.

wIs this a TODO?

---------------------------------------------------------------------------

Arguile wrote:
> On Wed, 2003-06-25 at 13:49, Tom Lane wrote:
> > There are a number of things that need to be done in psql before feature
> > freeze. Any comments on the following points?
> >
> > * We need a client-side autocommit-off implementation to substitute for
> > the one removed from the server. I am inclined to create a new psql
> > backslash command:
> > \autocommit on traditional handling of transactions
> > \autocommit off force BEGIN before any user command
> > that's not already in a transaction
> > \autocommit with no arg, show current state
> > An alternative to creating a new command is to define a special variable
> > in psql, whereupon the above three would instead be rendered
> > \set AUTOCOMMIT on
> > \set AUTOCOMMIT off
> > \echo :AUTOCOMMIT
> > The first choice seems less verbose to me, but if anyone wants to make a
> > case for the second, I'm open to it. Note that either of these could be
> > put in ~/.psqlrc if someone wants autocommit off as their default.
>
> A case for the latter is that it's very similar to environment
> variables, a well known system.
>
> The main advantage I see -- other than the shell similarities -- is the
> ability to call set with no arguments and get a listing of all the
> options. This is currently much shorter than the already overburdened \?
> screen and would concentrate all psql preference settings in one
> location.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-07-20 00:48:06 Re: [HACKERS] allowed user/db variables
Previous Message Bruce Momjian 2003-07-19 22:29:01 Re: dblink_ora - a first shot on Oracle ...