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. * 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org