Re: psql blows up on BOM character sequence - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql blows up on BOM character sequence
Date
Msg-id 26038.1395437293@sss.pgh.pa.us
Whole thread Raw
In response to Re: psql blows up on BOM character sequence  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: psql blows up on BOM character sequence
Re: psql blows up on BOM character sequence
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Surely if it were really a major annoyance, someone would have sent code 
> to fix it during the last 4 years and more since the above.

The code would probably be pretty trivial, *if* we had consensus on
what the behavior ought to be.  I'm not sure if we do.  People who
only use Unicode would probably like it if BOMs were unconditionally
swallowed, whether or not psql thinks the client_encoding is UTF8.
(And I seem to recall somebody even proposing that finding a BOM
be cause to switch the client_encoding to UTF8.)  However, these
ideas are complete nonstarters for people who habitually use other
encodings.

The argument about SQL syntax carries no weight for me, at least --- what
about COPY data files?  And I don't really want to suppose that \i can
never be used to insert a portion of a SQL command, either.

I'd be okay with swallowing a leading BOM if and only if client encoding
is UTF8.  This should apply to any file psql reads, whether script or
data.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "MauMau"
Date:
Subject: Re: [RFC] What should we do for reliable WAL archiving?
Next
From: Merlin Moncure
Date:
Subject: Re: psql blows up on BOM character sequence