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 по дате отправления: