Re: Fix PQport to never return NULL if the connection is valid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix PQport to never return NULL if the connection is valid
Date: 2025-07-17 16:58:36
Message-ID: 1540897.1752771516@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote:
>> ... 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.

Cool, done that way.

I ended up using Daniele's patches verbatim -- the first one in
v18/HEAD and the second in older branches. There was some discussion
of whether v18/HEAD should return an empty string if the connection is
bad, but I don't think that'd be helpful; the other inquiry functions
don't act that way. (But I left in the documentation text claiming
that we might do so, since perhaps such behavior would become
necessary in future.)

Also I didn't bother to remove the test for whether the port string
is empty. As you noted, it's not really necessary in the older
branches, but it is needed in v18/HEAD and it seemed better to
keep the code looking as similar as possible.

I dug around and could not find any indication of similar bugs
elsewhere in libpq. I did find that the documentation of the
port field was a lie:

char *port; /* port number (always provided) */

so I fixed that. This might be archaeological evidence of how
the bug came to be: apparently the original intent was for this
field to always be accurate, and when that changed, PQport
did not get the memo.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-07-17 17:03:25 Re: simple patch for discussion
Previous Message Jacob Champion 2025-07-17 16:48:29 Re: libpq: Process buffered SSL read bytes to support records >8kB on async API