Re: snprintf assert is broken by plpgsql #option dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: snprintf assert is broken by plpgsql #option dump
Date
Msg-id 18946.1538687834@sss.pgh.pa.us
Whole thread Raw
In response to snprintf assert is broken by plpgsql #option dump  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: snprintf assert is broken by plpgsql #option dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> There are new assert
> Assert(strvalue != NULL);
> probably all refname usage inside plpgsql dump functions has problem with
> it.

This isn't so much a "new assert" as a modeling of the fact that some
printf implementations dump core on a null string pointer, and have done
so since the dawn of time.

Now that we only use snprintf.c in HEAD, it'd be possible to consider
modeling glibc's behavior instead, ie instead of the Assert do

    if (strvalue == NULL)
        strvalue = "(null)";

I do not think this would be a good idea though, at least not till all
release branches that *don't* always use snprintf.c are out of support.
Every assert failure that we find here is a live bug in the back
branches, even if it happens not to occur on $your-favorite-platform.

Even once that window elapses, I'd not be especially on board with
snprintf.c papering over such cases.  They're bugs really.

> I found two parts

Thanks for the report, will push something.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: executor relation handling
Next
From: Tom Lane
Date:
Subject: Re: snprintf assert is broken by plpgsql #option dump