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]
---
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 clien
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?
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]
---
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.
H
Peter Eisentraut writes:
> Tom Lane wrote:
>> 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
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
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 usefu
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
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
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 o
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 PROT
12 matches
Mail list logo
