pgsql: Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT .

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(-)

Browse pgsql-committers by date

  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().