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

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: Should CSV parsing be stricter about mid-field quotes?
Дата
Msg-id 79f0b67a-c526-4f5b-a7cf-9bafea2f4ee4@app.fastmail.com
обсуждение исходный текст
Ответ на Re: Should CSV parsing be stricter about mid-field quotes?  ("Daniel Verite" <daniel@manitou-mail.org>)
Ответы Re: Should CSV parsing be stricter about mid-field quotes?  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: Should CSV parsing be stricter about mid-field quotes?  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
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?
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.

/Joel



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

Предыдущее
От: "Joel Jacobson"
Дата:
Сообщение: Re: New COPY options: DELIMITER NONE and QUOTE NONE
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: PG 16 draft release notes ready