| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: XMLNAMESPACES (was Re: Clarification of nodeToString() use cases) |
| Date: | 2018-09-16 19:32:27 |
| Message-ID: | 87fty9jl43.fsf@news-spur.riddles.org.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | farjad.farid | 2018-09-16 19:35:06 | RE: Code of Conduct plan |
| Previous Message | Douglas Doole | 2018-09-16 19:00:52 | Re: Collation versioning |