Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Also, as far as I understand what we want to control here is the
> encoding that the strings are in (the mapping of bytes to characters),
> not the collation (the way a set of strings are ordered). So it doesn't
> make sense to set the NATIONAL CHARACTER option using the COLLATE
> keyword.
My thought is that we should simply ignore the NATIONAL CHARACTER syntax,
which is not the first nor the last brain-damaged feature design in the
SQL standard. It's basically useless for what we want because there's
noplace to specify which encoding you mean. Instead, let's consider that
COLLATE can define not only the collation but also the encoding of a
string datum. Contrary to what I think you meant above, that seems
perfectly sensible to me, because after all a collation is necessarily a
bunch of rules about how to order a particular set of characters. If the
data representation you use is unable to represent that set of characters,
it's not a very meaningful combination is it?
There's still the problem of how do you get a string of a nondefault
encoding into the database in the first place. If you have to convert
to DB encoding to get it in there, then what's the use of a further
conversion? This consideration may well kill the whole concept.
(It certainly kills NATIONAL CHARACTER syntax just as much.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
