Re: [PATCH] Connection time for \conninfo - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCH] Connection time for \conninfo
Date
Msg-id 20200310181511.GK3195@tamriel.snowman.net
Whole thread Raw
In response to Re: [PATCH] Connection time for \conninfo  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Connection time for \conninfo  (Rodrigo Ramírez Norambuena <decipher.hk@gmail.com>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Anyway, I don't anticipate having time to do anything with this patch
> > but I disagree that this is a "we don't want it" kind of thing, rather
> > we maybe want it, since someone cared enough to write a patch, but the
> > patch needs work and maybe we want it to look a bit different and be
> > better defined.
>
> I think Peter's primary argument was that this doesn't belong in
> \conninfo, which is about reporting the parameters required to
> establish the connection.  We have kind of broken that already by
> cramming SSL and GSS encryption info into the results, but that
> doesn't mean it should become a kitchen-sink listing of anything
> anybody says they'd like to know.

I could certainly agree with wanting to have a psql command that's "give
me what I need to connect", but that idea and what conninfo actually
returns are pretty distant from each other.  For one thing, if I wanted
that from psql, I'd sure hope to get back something that I could
directly use when starting up a new psql session.

> Anyway, I think your point is that maybe this should be RWF
> not Rejected, and I agree with that.

Ok.

> (I had not looked at the last version of the patch, but now that
> I have, I still don't like the fact that it has the client tracking
> session start time separately from what the server does.  The small
> discrepancy that introduces is going to confuse somebody.  I see
> that there's no documentation update either.)

This worries me about as much as I worry that someone's going to be
confused by explain-analyze output vs. \timing.  Yes, it happens, and
actually pretty often, but I wouldn't change how it works because
they're two different things, not to mention that if I'm going to be
impacted by the time being off on one of the systems, I'd at least like
to know when my client thought it connected relative to the clock on my
client.

THanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: backend type in log_line_prefix?
Next
From: Justin Pryzby
Date:
Subject: Re: pg_ls_tmpdir to show directories and shared filesets (andpg_ls_*)