>> The existing \conninfo command gets its values from libpq APIs. You are >> changing all of this to make a server query, which is a totally >> different thing. If we wanted to take a change like this, I don't think >> it should be reusing the \conninfo command.
FWIW, I agree with Peter's concern here, for a couple of reasons: * If \conninfo involves a server query, then it will fail outright if the server is in an aborted transaction, or if there's something wrong with the connection --- which seems like one of the primary cases where you'd wish to use \conninfo. * What if there's a discrepancy between what libpq thinks and what the server thinks? (This is hardly unlikely for, say, host names.) In the current situation you can use \conninfo to investigate the client-side parameters and then use a manual query to see what the server thinks. If we replace \conninfo with a server query then there is no way at all to verify libpq parameters from the psql command line. So I concur that \conninfo should continue to report on libpq values and nothing else. We can certainly talk about expanding it within that charter, if there's useful stuff it doesn't show now. But a command that retrieves settings from the server should be a distinct thing. ---//--- Well, I can revert \conninfo to its original state and keep \conninfo+ as it is, perhaps removing the application name, as I believe everything else is important for a DBA/SysAdmin. Do you think we can proceed with the patch this way? I am open to ideas that make \conninfo not limited to just four or five basic pieces of information and easily bring everything else to the screen. Regards, Maiquel Grassi.