| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UTF8 with BOM support in psql |
| Date: | 2009-10-20 16:02:01 |
| Message-ID: | 9837222c0910200902y4e0ad560o1c188e0f495f8b15@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2009/10/20 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> What I think we might sensibly do is to eat the leading BOM of an SQL
>> file iff the client encoding is UTF8, and otherwise treat it as just
>> bytes in whatever the encoding is.
>
> That seems relatively non-risky.
+1.
>> Should we also do the same for files passed via \copy? What about
>> streams on stdin? What about files read from the backend via COPY?
>
> Not thrilled about doing this on stdin --- you have no good
> justification for assuming that start of stdin corresponds to a file
> boundary somewhere. COPY files, maybe.
Yeah, that seems a lot more error-prone.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Christensen | 2009-10-20 16:02:02 | Re: UTF8 with BOM support in psql |
| Previous Message | Magnus Hagander | 2009-10-20 16:00:59 | Re: Application name patch - v2 |