Re: [PATCH] Connection time for \conninfo

Hi There!

I forgot about that ... It passed a little time from my new pushed
changes. So go ahead :)

On Tue, Mar 10, 2020 at 3:15 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)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.

So if the path it set as RWF could push a extra work in there but in
main point what be the address about that.

Thanks to all for you feedback.
Regards!
--
Rodrigo Ramírez Norambuena
http://www.rodrigoramirez.com/