Re: psql blows up on BOM character sequence

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql blows up on BOM character sequence
Дата
Msg-id 26038.1395437293@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql blows up on BOM character sequence  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: psql blows up on BOM character sequence  (Merlin Moncure <mmoncure@gmail.com>)
Re: psql blows up on BOM character sequence  (Tatsuo Ishii <ishii@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: "MauMau"
Дата:
Сообщение: Re: [RFC] What should we do for reliable WAL archiving?
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: psql blows up on BOM character sequence