Re: Psql meta-command conninfo+ - Mailing list pgsql-hackers

From Imseih (AWS), Sami
Subject Re: Psql meta-command conninfo+
Date
Msg-id FF0CFD66-4ED2-421F-B2E6-87B4BD71C4A9@amazon.com
Whole thread Raw
In response to Re: Psql meta-command conninfo+  (Peter Eisentraut <peter@eisentraut.org>)
Responses RE: Psql meta-command conninfo+
List pgsql-hackers
> The original \conninfo was designed to report values from the libpq API
> about what libpq connected to. And the convention in psql is that "+"
> provide more or less the same information but a bit more. So I think it
> is wrong to make "\conninfo+" something fundamentally different than
> "\conninfo".

That is a fair argument. Looking at this a bit more, it looks like we can
enhance the GSSAPI output of conninfo to get the fields that GSSAPI fields that
conninfo+ was aiming for

Right now it just shows:

printf(_("GSSAPI-encrypted connection\n"));

but we can use libpq to get the other GSSAPI attributes in the output.

> And even more so if it contains information that isn't really
> "connection information". For example, current_user() doesn't make
> sense here, I think.

> I mean, if you want to add a command \some_useful_status_information, we
> can talk about that, but let's leave \conninfo to what it does.

> But I think there are better ways to implement this kind of server-side
> status, for example, with a system view.

What about a \sessioninfo command that shows all the
information for the current session, PID, app_name, current_user,
session_user, system_user, client_address, client_port, etc.

These will be the fields that we cannot gather if the connection is
broken for whatever reason.

The distinction here is \sessioninfo are the details after the connection
is established and could possibly be changed during the connection.

Regards,

Sami



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixing backslash dot for COPY FROM...CSV
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs