On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote: > Laurenz Albe <laurenz.a...@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
