Peter Eisentraut <peter_e@gmx.net> writes:
> I think it comes down to defining what we really want. Clearly, "char" is
> a byte, not a character, much like in C. Perhaps we should adopt the
> bytea escape mechanism for "char" values above 127. Otherwise, what gets
> stored and what gets printed out both depends on character set conversion
> issues, which seems yucky.
That would be okay with me.
> Now you can define name[x] to be the x'th *byte* of name, but that seems
> contrived and inconsistent with the original purpose, because whether you
> get useful or garbage values depends on the character set encoding.
"Original purpose" is in the eye of the beholder, maybe. It's not
practical to fix name subscripting to make it be multibyte-aware
(not least because the output type couldn't be "char"). So the only
alternative to leaving it alone is to remove the capability entirely.
Which strikes me as overly rigid. It is a useful facility for people
using 1-byte character sets, and I see no reason to take it away from
them just because it isn't very useful in multibyte character sets.
> Btw., the issue is even a bit more serious than the example I posted:
> $ dropdb test
> $ createdb -E UNICODE test
> $ psql test
> => create table �land (a int);
> => \d
> ERROR: Could not convert UTF-8 to ISO8859-1
I suspected that that issue didn't really have anything to do with
subscripting, and I guess I was right. But I still can't duplicate
the error. I take it you are using client_encoding ISO8859-1 ...
but what exactly is the funny character involved? It comes across
here as \345 but I bet something munged it in transmission, because
what I see is
test=# create table �land (a int);
CREATE TABLE
test=# \d List of relationsSchema | Name | Type | Owner
--------+------+-------+----------public | ,and | table | postgres
(1 row)
regards, tom lane
