Tom Lane wrote:
> Thomas Hallgren <thhal@mailblocks.com> writes:
>
>>Why not use standard C semantics for the textual representation with
>>your addition that empty items are NULL?
>
>
> This isn't C, it's SQL; and I think the array I/O representation is a
> closer precedent for us than the C standard.
>
> In any case, how much of C syntax are you proposing to emulate exactly?
> Comments? Backslashed newlines? Joining of adjacent double-quoted
> strings? Conversion of octal and hex integer constants (and what about
> L, U, LL, etc suffixes)? There's a lot more stuff there than meets the
> eye, and most of it isn't something I want to code.
>
I'm not proposing a full C parser implementation :-) Just static data
initializer part.
To answer how much of the C syntax:
Comments, no. SQL has a standard for comments that doesn't conflict with
C semantics for data initializers.
Joining of adjacent double-quoted strings. Yes, of course. That's what
you already do for arrays today. Without this, it will be hard to write
long strings in a readable way.
Conversion of backslashed newlines, octal and integer constants within
strings, yes, why not? The issue of non-printables needs to be addressed
somehow. What do you propose?
Regarding the L, U, LL suffixes, depends in what way do you plan to
tackle different character sets. Perhaps UTF-8 with unicode escapes
would be better. Some mechanism i needed, that's for sure.
Kind regards,
Thomas Hallgren