On 12/21/19 10:08 AM, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> It appears that in pg11 (and presumably prior) when snprintf() is called
>> it is resolved (here at least )to __GI___snprintf() which comes directly
>> from libc. On my desktop machine the system snprintf() deals with a null
>> pointer argument without crashing. I guess this is why the crash was
>> platform dependent.
>
> Right, glibc's version of snprintf has produced "(nil)" or "(null)"
> or something like that for many years. I'm not sure if that's true
> among the BSDen. One place where the platform snprintf does *not*
> survive this case is Windows.
>
>> In pg12 (and presumably master), it is resolved to our own port function
>> pg_snprintf(), which in turn works its way to dopr(), where strlen() is
>> called on a null pointer and "<boom>".
>
> Right. While it would only take a couple more lines of code to act like
> glibc does, we intentionally adopted the stricter definition because it
> seemed more likely to expose bugs. Looks like it just did.
>
>> From what I can see, even on pg11 and prior, having a null category
>> never did anything useful. And in the 16 years or so since this has been
>> around, no one in my memory ever asked for that functionality, so I am
>> inclined to refuse NULL category values unless someone wants to make a
>> good case otherwise.
>
> WFM, but I've never used crosstab() much so I don't have a good feeling
> for significant use-cases.
Pushed that way to all supported branches.
If someone arrives with a compelling use-case, the changes would likely
not be something we would want to back patch, so we can address it
if/when that happens.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development