Horton
Menu

Re: Don't pass NULL pointer to strcmp().

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Xing Guo <higuoxing@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Junwang Zhao <zhjwpku@gmail.com>
Date: 2023-11-01T15:30:47Z
Lists: pgsql-hackers 
Xing Guo <higuoxing@gmail.com> writes:
> Thanks for your comments. I have updated the patch accordingly.

I'm leery of accepting this patch, as I see no reason that we
should consider it valid for an extension to have a string GUC
with a boot_val of NULL.

I realize that we have a few core GUCs that are like that, but
I'm pretty sure that every one of them has special-case code
that initializes the GUC to something non-null a bit later on
in startup.  I don't think there are any cases where a string
GUC's persistent value will be null, and I don't like the
idea of considering that to be an allowed case.  It would
open the door to more crash situations, and it brings up the
old question of how could a user tell NULL from empty string
(via SHOW or current_setting() or whatever).  Besides, what's
the benefit really?

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make GetConfigOption/GetConfigOptionResetString return "" for NULL.

  2. Be more wary about NULL values for GUC string variables.

  3. doc: Replace reference to ERRCODE_RAISE_EXCEPTION by "raise_exception"