Re: snprintf assert is broken by plpgsql #option dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: snprintf assert is broken by plpgsql #option dump
Date: 2018-10-04 21:17:14
Message-ID: 18946.1538687834@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-04 21:57:53 Re: snprintf assert is broken by plpgsql #option dump
Previous Message Tom Lane 2018-10-04 20:59:57 Re: executor relation handling