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