Hi, Although this is a ten-year-old message, it was the one I found quickly when looking to see what the current state of play on this might be.
On 2013-09-20 14:22, Robert Haas wrote:
Hmm. So under that design, a database could support up to a total of two character sets, the one that you get when you say 'foo' and the other one that you get when you say n'foo'. I guess we could do that, but it seems a bit limited. If we're going to go to the trouble of supporting multiple character sets, why not support an arbitrary number instead of just two?
Because that old thread came to an end without mentioning how the standard approaches that, it seemed worth adding, just to complete the record. In the draft of the standard I'm looking at (which is also around a decade old), n'foo' is nothing but a handy shorthand for _csname'foo' (which is a syntax we do not accept) for some particular csname that was chosen when setting up the db. So really, the standard contemplates letting you have columns of arbitrary different charsets (CHAR(x) CHARACTER SET csname), and literals of arbitrary charsets _csname'foo'. Then, as a bit of sugar, you get to pick which two of those charsets you'd like to have easy shorter ways of writing, 'foo' or n'foo', CHAR or NCHAR. The grammar for csname is kind of funky. It can be nothing but <SQL language identifier>, which has the nice restricted form /[A-Za-z][A-Za-z0-9_]*/. But it can also be schema-qualified, with the schema of course being a full-fledged <identifier>. So yeah, to fully meet this part of the standard, the parser'd have to know that _U&"I am a schema nameZ0021" UESCAPE 'Z'/*hi!*/.LATIN1'foo' is a string literal, expressing foo, in a character set named LATIN1, in some cutely-named schema. Never a dull moment. Regards, -Chap
