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
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 |