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   peter_e@gmx.net

Mon, 28 Jul 2003 09:49:41 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Passing server_encoding to the client is not future-proof
Peter Eisentraut <peter_e@gmx.net> 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

Mon, 28 Jul 2003 10:26:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 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   peter_e@gmx.net

Tue, 29 Jul 2003 14:20:18 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Passing server_encoding to the client is not future-proof
Peter Eisentraut <peter_e@gmx.net> 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

Tue, 29 Jul 2003 09:50:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Passing server_encoding to the client is not future-proof 
On Tue, 2003-07-29 at 09:50, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> 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.
29 Jul 2003 09:53:56 -0400
Rod Taylor <rbt@rbt.ca>
Re: 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


Tue, 29 Jul 2003 16:04:16 +0200
Carlos Guzman Alvarez <carlosga@telefonica.net>
Re: Passing server_encoding to the client is not future-proof
JDBC guys, why do you need to know the server encoding?

Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.net> 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.

-- 
Peter Eisentraut   peter_e@gmx.net

Wed, 30 Jul 2003 09:54:20 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
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   peter_e@gmx.net


Sun, 31 Aug 2003 21:06:17 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: 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   peter_e@gmx.net


Sun, 31 Aug 2003 21:09:58 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Passing server_encoding to the client is not future-proof