Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-08-31 Thread Peter Eisentraut
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-08-31 Thread Peter Eisentraut
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-08-31 Thread Peter Eisentraut
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]

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-08-14 Thread Peter Eisentraut
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]

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-08-06 Thread Tom Lane
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.

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-07-29 Thread Peter Eisentraut
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-07-29 Thread Tom Lane
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-07-29 Thread Rod Taylor
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-07-29 Thread Carlos Guzman Alvarez
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

[HACKERS] Passing server_encoding to the client is not future-proof

2003-07-28 Thread Peter Eisentraut
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

Re: [HACKERS] Passing server_encoding to the client is not future-proof

2003-07-28 Thread Tom Lane
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