Re: [RFC] nodeToString format and exporting the SQL parser
От | Michael Tharp |
---|---|
Тема | Re: [RFC] nodeToString format and exporting the SQL parser |
Дата | |
Msg-id | 4BD39620.6080101@partiallystapled.com обсуждение исходный текст |
Ответ на | Re: [RFC] nodeToString format and exporting the SQL parser (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [RFC] nodeToString format and exporting the SQL parser
|
Список | pgsql-hackers |
On 04/24/2010 08:49 PM, Robert Haas wrote: >> The nodeToString format as it stands is somewhat ambiguous with respect to >> the type of a node member's value if one does not have access to >> readfuncs.c. For example, a T_BitString called foo is serialized as ':foo >> b1010' while a char * containing 'b1010' is also serialized as ':foo b1010'. >> This may just mean that _outToken needs to escape the leading 'b'. A similar >> problem exists for booleans ('true' as a string vs. as a boolean). > > I am not inclined to change this. Turning the format into something > self-describing seems to me to be significant work and a significant > compatibility break for a very small amount of benefit. The funny thing is, it doesn't seem to be a compatibility break because the code in readfuncs.c that parses the node strings ignores the field names entirely because it assumes they are in a particular order. It also isn't much work to change the output because the code is, with the exception of a few weirdos, all at the top of outfuncs.c, and the weirdos are also dispersed within that file. However, I'm no longer convinced that using a serialized node tree is the way to go for my use case, nor am I particularly sure that it even matches my use case at all anymore as I keep simplifying the goals as time goes on. I won't be able to make any compelling arguments until I figure out what I need :-) Thanks for the feedback. -- m. tharp
В списке pgsql-hackers по дате отправления: