16.09.2018 23:05, Tom Lane writes:
Andrey Lepikhov <a.lepik...@postgrespro.ru> writes:
The reason is: parse tree node for XMLNAMESPACES clause has null pointer
in the case of DEFAULT namespace (the pointer will be initialized at
executor on the first call).
My immediate reaction is that somebody made a bad decision about how
to represent XMLNAMESPACES clauses. It's not quite too late to fix
that; but could you offer a concrete example that triggers this,
so it's clear what case we're talking about?
The change the attached patch makes is to represent a DEFAULT namespace
as a NULL list entry, rather than a T_String Value node containing a
null. This approach does work for all backend/nodes/ operations, but
it could be argued that it's still a crash hazard for unsuspecting code.
We could do something else, like use a T_Null Value to represent DEFAULT,
but I'm doubtful that that's really much better. A NULL entry has the
advantage (or at least I'd consider it one) of being a certain crash
rather than a probabilistic crash for any uncorrected code accessing
the list item. Thoughts?
You correctly defined the problem in more general formulation at your
next thread [1].
Thank you for this patch. May be it is not universal solution for
DEFAULT values, but now it works fine.
Note, however, that if we emphasize comments by DEBUG purpose of
nodeToString(), it can reduce the same mistakes and questions in the future.
[1] More deficiencies in outfuncs/readfuncs processing:
https://www.postgresql.org/message-id/17114.1537138...@sss.pgh.pa.us
--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company
