Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)
От | Andrew Gierth |
---|---|
Тема | Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases) |
Дата | |
Msg-id | 87fty9jl43.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases)
|
Список | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> 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 still a crash hazard Tom> for unsuspecting code. We could do something else, like use a Tom> T_Null Value to represent DEFAULT, but I'm doubtful that that's Tom> really much better. A NULL entry has the advantage (or at least Tom> I'd consider it one) of being a certain crash rather than a Tom> probabilistic crash for any uncorrected code accessing the list Tom> item. Thoughts? Seems reasonable to me. Tom> + Value *ns_node = (Value *) lfirst(lc2); lfirst_node(Value, lc2) maybe? -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: