| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Emmanuel Cecchet <manu(at)asterdata(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: COPY enhancements |
| Date: | 2009-10-09 13:52:18 |
| Message-ID: | 7082.1255096338@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> writes:
> On Thu, 2009-10-08 at 11:32 -0400, Robert Haas wrote:
>> Another possible approach, which isn't perfect either, is the idea of
>> allowing COPY to generate a single column of output of type text[].
>> That greatly reduces the number of possible error cases,
> maybe make it bytea[] to further reduce error cases caused by charset
> incompatibilities ?
That seems likely to be considerably less convenient and more error
prone, as it now puts it on the user to do the correct conversion.
It does bring up an interesting point for error handling though, which
is what do we do with rows that fail encoding conversion? For logging
to a file we could/should just decree that we write out the original,
allegedly-in-the-client-encoding data. I'm not sure what we do about
logging to a table though. The idea of storing bytea is pretty
unpleasant but there might be little choice.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2009-10-09 14:53:45 | Re: Review of "SQLDA support for ECPG" |
| Previous Message | Tom Lane | 2009-10-09 13:44:42 | Re: COPY enhancements |