From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT . |
Date: | 2018-09-17 17:16:44 |
Message-ID: | E1g1x8e-0007qC-14@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
REL_11_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/486cfb3b8ce6e94eaad48038acff51064c070ccb
Modified Files
--------------
src/backend/executor/nodeTableFuncscan.c | 6 +++++-
src/backend/parser/parse_clause.c | 15 ++++++++-------
src/backend/utils/adt/ruleutils.c | 6 +++---
src/include/nodes/execnodes.h | 4 ++--
src/include/nodes/primnodes.h | 7 +++++--
5 files changed, 23 insertions(+), 15 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-09-17 18:30:40 | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Previous Message | Tom Lane | 2018-09-17 16:43:13 | pgsql: Remove dead code from pop_next_work_item(). |