Re: snprintf assert is broken by plpgsql #option dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-04T21:17:14Z
Lists: 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
Commits
-
Ensure that PLPGSQL_DTYPE_ROW variables have valid refname fields.
- 6e526b78706a 11.0 landed
- 113a659914da 12.0 landed