diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-09-17 13:16:32 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-09-17 13:16:32 -0400 |
commit | 486cfb3b8ce6e94eaad48038acff51064c070ccb (patch) | |
tree | ed706220a25792a791940d3aa19a031a0e5f86bf /src/backend/executor/nodeHashjoin.c | |
parent | d45f157e8b07aee455df0bcc76fdf4e9963c0200 (diff) | |
download | postgresql-486cfb3b8ce6e94eaad48038acff51064c070ccb.tar.gz postgresql-486cfb3b8ce6e94eaad48038acff51064c070ccb.zip |
Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT ...)).
The original coding for XMLTABLE thought it could represent a default
namespace by a T_String Value node with a null string pointer. That's
not okay, though; in particular outfuncs.c/readfuncs.c are not on board
with such a representation, meaning you'll get a null pointer crash
if you try to store a view or rule containing this construct.
To fix, change the parsetree representation so that we have a NULL
list element, instead of a bogus Value node.
This isn't really a functional limitation since default XML namespaces
aren't yet implemented in the executor; you'd just get "DEFAULT
namespace is not supported" anyway. But crashes are not nice, so
back-patch to v10 where this syntax was added. Ordinarily we'd consider
a parsetree representation change to be un-backpatchable; but since
existing releases would crash on the way to storing such constructs,
there can't be any existing views/rules to be incompatible with.
Per report from Andrey Lepikhov.
Discussion: https://postgr.es/m/3690074f-abd2-56a9-144a-aa5545d7a291@postgrespro.ru
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions