Re: [HACKERS] Passing server_encoding to the client is not future-proof
Carlos Guzman Alvarez writes: The JDBC guys wanted to know it. Why is not clear to me, but I figured it was easy enough to make them happy. I'm using it too in my .NET Data Provider for allow atomatic encoding of strings before send it to the server. Why would you want to do that? The server can do the encoding conversion. You're bound to get into trouble using this approach. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: One of the reasons for not doing conversion in binary mode is to have an escape hatch for unconvertible characters, eg for dump purposes. That functionality is already provided by setting the client encoding to SQL_ASCII. Hm. Okay, so are you arguing that we should not remove encoding conversion from the binary-transmission case? I think a binary mode for text is pretty useless, at least compared to binary modes for numbers and other data types, where they are clearly useful. Therefore, we should keep the binary mode the same as the normal mode and just label it binary. (I assume it's not practical to not have a binary mode for particular data types.) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Tom Lane writes: The JDBC guys wanted to know it. Why is not clear to me, but I figured it was easy enough to make them happy. The JDBC guys didn't respond, and I don't see it used in their source code, so I'm inclined to remove it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Tom Lane writes: One of the reasons for not doing conversion in binary mode is to have an escape hatch for unconvertible characters, eg for dump purposes. That functionality is already provided by setting the client encoding to SQL_ASCII. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: One of the reasons for not doing conversion in binary mode is to have an escape hatch for unconvertible characters, eg for dump purposes. That functionality is already provided by setting the client encoding to SQL_ASCII. Hm. Okay, so are you arguing that we should not remove encoding conversion from the binary-transmission case? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Tom Lane writes: Clients could probably still make use of server_encoding, though I'm unclear on what they'd use it for now, let alone then. ISTM client_encoding is the only setting the client need deal with directly. Then why did we add a GUC variable server_encoding at all? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Peter Eisentraut [EMAIL PROTECTED] writes: Then why did we add a GUC variable server_encoding at all? The JDBC guys wanted to know it. Why is not clear to me, but I figured it was easy enough to make them happy. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Passing server_encoding to the client is not future-proof
On Tue, 2003-07-29 at 09:50, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Then why did we add a GUC variable server_encoding at all? The JDBC guys wanted to know it. Why is not clear to me, but I figured it was easy enough to make them happy. It could still be useful for stored procedures (particularly Java ones) which would have to deal with the encoding at the server. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Hello: The JDBC guys wanted to know it. Why is not clear to me, but I figured it was easy enough to make them happy. I'm using it too in my .NET Data Provider for allow atomatic encoding of strings before send it to the server. -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Passing server_encoding to the client is not future-proof
Has anyone thought of what will happen to the server_encoding parameter when the character set/encoding will be settable for individual columns and the concept of a global server encoding will go away? What will happen to clients that make use of this parameter? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Passing server_encoding to the client is not future-proof
Peter Eisentraut [EMAIL PROTECTED] writes: Has anyone thought of what will happen to the server_encoding parameter when the character set/encoding will be settable for individual columns and the concept of a global server encoding will go away? What will happen to clients that make use of this parameter? I would imagine that we'd keep the concept of a per-database encoding, but it would be become a default value for per-column encoding choices, rather than the One True Value. Clients could probably still make use of server_encoding, though I'm unclear on what they'd use it for now, let alone then. ISTM client_encoding is the only setting the client need deal with directly. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
