On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote:
> > > Please find attached a new patch that doesn't change the behaviour and
> > > just makes sure to not return NULL in case no info is available in
> > > 'conn->connhost'.
>
> > I think that it is important to fix that bug and to backpatch it.
> > Without the patch, I can produce the following crash:
>
> > $ psql port=
> > psql (18beta1)
> > Type "help" for help.
>
> > test=> \conninfo
> > Segmentation fault (core dumped)
>
> This crash is actually new in v18
That is a relief.
> Having said that, I agree with back-patching Daniele's fix
> However ... I wonder if we ought to take the opportunity to fix
> \conninfo to ensure that it prints something useful rather than
> just an empty string? The upgrade to make it print in tabular
> format is what broke this, but it also seems like an excuse to
> improve the functionality as well as the cosmetics.
>
> However, fixing this in \conninfo seems a bit tedious: we'd have
> to grovel through the output of PQconndefaults. (I don't think
> it's okay for psql to assume that it can rely on having been
> built with the same value of DEF_PGPORT_STR that the libpq it's
> linked to is using.) So it seems attractive to stick with the
> original thought of making PQport substitute the correct value
> for an empty string. PQport *does* know the correct value of
> DEF_PGPORT_STR, so it'd be pretty nearly a one-liner to make
> this happen there.
>
> I'd only propose doing this in v18/HEAD, and sticking to the
> v2 patch in the stable branches.
That makes a lot of sense.
As long as the information is factually correct, it is a good
idea to have \conninfo return more complete data.
Yours,
Laurenz Albe
