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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Passing server_encoding to the client is not future-proof
Date: 2003-07-28 14:26:52
Message-ID: 9167.1059402412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-07-28 14:28:25 Re: "is_superuser" parameter creates inconsistencies
Previous Message Tom Lane 2003-07-28 14:23:43 Re: SQLSTATEs for warnings

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dmitry Tkach 2003-07-28 14:32:54 Re: Another exception (Transaction level)
Previous Message Fernando Nasser 2003-07-28 14:15:05 Re: Another exception (Transaction level)