| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: UTF8 with BOM support in psql |
| Date: | 2009-10-20 15:51:31 |
| Message-ID: | 28242.1256053891@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-10-20 15:53:03 | Re: Controlling changes in plpgsql variable resolution |
| Previous Message | David Fetter | 2009-10-20 15:48:59 | Re: Could postgres be much cleaner if a future release skipped backward compatibility? |