Re: Should CSV parsing be stricter about mid-field quotes?

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Should CSV parsing be stricter about mid-field quotes?
Дата
Msg-id 20230702054531.GA1230904@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: Should CSV parsing be stricter about mid-field quotes?  ("Joel Jacobson" <joel@compiler.org>)
Список pgsql-hackers
On Sat, May 20, 2023 at 09:16:30AM +0200, Joel Jacobson wrote:
> On Fri, May 19, 2023, at 18:06, Daniel Verite wrote:
> > COPY FROM file CSV somewhat differs as your example shows,
> > but it still mishandle \. when unquoted. For instance, consider this
> > file to load with COPY    t FROM '/tmp/t.csv' WITH CSV
> > $ cat /tmp/t.csv
> > line 1
> > \.
> > line 3
> > line 4
> >
> > It results in having only "line 1" being imported.
> 
> Hmm, this is a problem for one of the new use-cases I brought up that would be
> possible with DELIMITER NONE QUOTE NONE, i.e. to import unstructured log files,
> where each raw line should be imported "as is" into a single text column.
> 
> Is there a valid reason why \. is needed for COPY FROM filename?

No.

> It seems to me it would only be necessary for the COPY FROM STDIN case,
> since files have a natural end-of-file and a known file size.

Right.  Even for COPY FROM STDIN, it's not needed anymore since the removal of
protocol v2.  psql would still use it to find the end of inline COPY data,
though.  Here's another relevant thread:
https://postgr.es/m/flat/bfcd57e4-8f23-4c3e-a5db-2571d09208e2%40beta.fastmail.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Miroslav Bendik
Дата:
Сообщение: Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Fdw batch insert error out when set batch_size > 65535