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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updating psql for features of new FE/BE protocol
Date: 2003-06-25 20:24:01
Message-ID: 200306252024.h5PKO1829294@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

I thought we were trying to get away from multi-letter backslash
variables like \connect. I think we should use \set,\echo, though of
course, those are multi-letter too, so maybe it isn't an issue. I just
find \df and \df_and_more_letters_that_make_a_word to just be weird.

> * Since libpq now keeps track of transaction state, it would be a simple
> matter to add a prompt-string % construct to show something that indicates
> the state (with possible values "idle", "in transaction", "in failed
> transaction"). Any thoughts about exactly what this ought to look like?
> I prototyped it with code that showed 'I', 'T', or 'E' but I suspect that
> non-alphabetic characters would be better, since they wouldn't look like
> part of a database name or other things you might put in the prompt.
>
> BTW, both of the above features will work against pre-7.4 servers, with
> the exception that a 7.3 server running with server-side autocommit off
> will confuse libpq's tracking of transaction state. Not sure how
> important that really is, given that we don't recommend running psql
> against servers of different versions.

Don't worry about old servers in this regard.

> * I plan to get rid of psql's startup-time query to find out if you are
> superuser, and instead let the '#' vs '>' prompt be driven through another
> ParameterStatus variable, per a proposal I made awhile ago. (If anyone
> can propose a better name for the GUC variable than "am_superuser", let's

I think 'is_superuser' is more appropriate.

--
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-25 20:27:12 Re: Feature freeze and the great elog changeover
Previous Message Tom Lane 2003-06-25 20:11:30 Re: Many Pl/PgSQL parameters -> AllocSetAlloc(128)?