Re: Updating psql for features of new FE/BE protocol - Mailing list 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073