Thomas Hallgren <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
