| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add ENCODING option to COPY |
| Date: | 2011-01-31 16:25:38 |
| Message-ID: | 17784.1296491138@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
> Finally I concluded the concern Itagaki-san raised can be solved by
> adding code that restores client_encoding in copy_in_error_callback.
That seems like an absolutely horrid idea. Error context callbacks
should not have side-effects like that. They're not guaranteed to be
called at all, let alone in any particular order. In this case I'd also
be worried that the state needs to be fixed before elog.c reaches the
point of calling the callbacks --- there's nothing to say that it might
not try to translate some strings to the client encoding earlier than
that.
It might happen to work today (or at least in the scenarios you tested),
but it seems fragile as can be.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-01-31 16:29:05 | Re: Allowing multiple concurrent base backups |
| Previous Message | Robert Haas | 2011-01-31 16:24:22 | Re: Error code for "terminating connection due to conflict with recovery" |