Re: Client encoding conversion for binary data (was Re:

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Client encoding conversion for binary data (was Re:
Date: 2003-05-15 14:25:51
Message-ID: 1053008751.1693.29.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane kirjutas N, 15.05.2003 kell 15:54:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > I have not been closely following the discussion about FE/BE protocol
> > changes, but the way converting binary seems dangerous - if you insert a
> > .gif file into bytea column using decode(encodedgiffile,'base64'), but
> > would like to get it out in binary for performance reasons, it is not
> > good if it gets run through conversion routines.
>
> bytea does not get converted in any case. The issue here is what to do
> about text datatypes.

For me the logical behaviour is :

1) all text moving between client and server should be converted

2) text staying on server should stay in server encoding.

3) if someone has to move text produced by \copy on server, let hin do
it using a postgresql function defined as "read_text(path) returns text"
so the file gets converted using standard mechanisms.

4) for special cases we could add WITH CLIENTENCODING to copy

-------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-05-15 15:39:37 Re: Client encoding conversion for binary data (was Re:
Previous Message Cédric Coulon 2003-05-15 13:46:18 predict conflict