Updating psql for features of new FE/BE protocol - Mailing list pgsql-hackers

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

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

* 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
hear it.)  If I remove the startup query entirely, then when talking to
pre-7.4 servers the prompt would always show '>'.  It'd be possible to
continue to issue the query against pre-7.4 servers only, but is it worth
the trouble?  Again, we don't go to much trouble to make psql work 100%
with old servers.

* We can get rid of psql's LO_TRANSACTION variable, or at least make the
behavior more robust, now that psql can see the current transaction state.
Two cases are pretty obvious: if idle, then start and end our own
transaction around the LO operation.  If in a transaction, do not issue
BEGIN or COMMIT, but just use that transaction.  The third case is what
to do if in a failed transaction.  You could argue that the LO operation
should be allowed to fail as well.  Alternatively, we could roll back the
failed xact and then proceed as in the idle case.  Anyone have a good case
to make for either choice?  Should we redefine LO_TRANSACTION to allow
both choices to be supported?  Does anyone feel that the existing
LO_TRANSACTION behaviors of forced-rollback or forced-commit of open
transactions should continue to be supported?

* \encoding can be driven from ParameterStatus too, thus making it more
robust (it will correctly show an encoding set via a SET command).

Opinions welcome ...
        regards, tom lane