Group: pgsql.interfaces.jdbc


Subject: JDBC driver patch for non-ASCII users
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/7/2007 9:51:55 PM
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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

Subject: JDBC driver patch for non-ASCII users
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/8/2007 2:47:56 AM
Kris Jurka <books@ejurka.com> writes: > The original patch's suggested use of the client's environment > encoding seems random to me. Yeah, that bothered me too --- it seemed to be introducing a whole new variable into the behavior, without much to show for it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster