Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-17 Thread Andrew Dunstan
On 09/16/2018 11:11 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/16/2018 02:05 PM, Tom Lane wrote: 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. Seems related to this CF item that's bee

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Andrey Lepikhov
16.09.2018 23:05, Tom Lane writes: Andrey Lepikhov 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

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Tom Lane
Andrew Dunstan writes: > On 09/16/2018 02:05 PM, Tom Lane wrote: >> 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. > Seems related to this CF item that's been around for a year: >

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Andrew Dunstan
On 09/16/2018 02:05 PM, Tom Lane wrote: I wrote: Andrey Lepikhov 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

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Tom Lane
Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> + Value*ns_node = (Value *) lfirst(lc2); > lfirst_node(Value, lc2) maybe? Unfortunately not: the node tag is not T_Value but T_String. regards, tom lane

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Andrew Gierth
> "Tom" == Tom Lane writes: Tom> The change the attached patch makes is to represent a DEFAULT Tom> namespace as a NULL list entry, rather than a T_String Value node Tom> containing a null. This approach does work for all backend/nodes/ Tom> operations, but it could be argued that it's st

Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Tom Lane
I wrote: > Andrey Lepikhov 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 repr

XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)

2018-09-16 Thread Tom Lane
Andrey Lepikhov writes: > In the AQO project (Adaptive Query Optimization) [1] the nodeToString() > function is used by the planner to convert an query parse tree into a > string to generate a hash value [2]. Hmm. Not sure that is a bright idea; in fact, I'm pretty sure it's a *bad* idea. Thi

Clarification of nodeToString() use cases

2018-09-16 Thread Andrey Lepikhov
Hi, Hackers! In the AQO project (Adaptive Query Optimization) [1] the nodeToString() function is used by the planner to convert an query parse tree into a string to generate a hash value [2]. In PostgreSQL v.11 call nodeToString(parse) segfaulted. The reason is: parse tree node for XMLNAMESPAC