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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Douglas Doole
Дата:
Сообщение: Re: Collation versioning
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench - add pseudo-random permutation function