Oliver Jowett <oliver@opencloud.com> writes:
> I would also be a lot happier if the protocol specification docs were
> updated to reflect whatever the current "approved" way of doing
> non-ASCII authentication info is before the driver started making
> assumptions about it.
That's a bit hard, because the real problem here is that there isn't any
"approved" way of dealing with this. The short and unpleasant answer is
that if you put any non-7-bit-ASCII characters into shared system
catalogs (not only pg_authid, but pg_database and pg_tablespace),
You Are On Your Own. When it breaks, you get to keep both pieces.
Given the current design that allows different databases in a cluster
to (claim they) have different encodings, it's real hard to see how
to handle non-ASCII data in shared catalogs sanely. I don't think
we'll really be able to fix this properly until that mythical day
when we have support for per-column encoding selections. My guess
is that we'd then legislate that shared catalog columns are always
UTF8; after which we could start to think about what it would take
to do conversion of the connection startup packet's contents from
client-side encoding to UTF8.
Right now it's all pretty broken, and I really question whether it's
sane to put workarounds like this proposed patch into client-side
drivers. If you aren't consistent about the encoding you use for
non-ASCII usernames, you're going to lose somewhere along the line
anyway. So why not just recommend that people do that?
regards, tom lane