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

Поиск
Список
Период
Сортировка
От Kirk Wolak
Тема Re: Should CSV parsing be stricter about mid-field quotes?
Дата
Msg-id CACLU5mRj48yYnEj7k3xYFbsNkgG5NsZO7NxQQLM03G9HHQYuqw@mail.gmail.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>)
Список pgsql-hackers
On Mon, May 22, 2023 at 12:13 PM Daniel Verite <daniel@manitou-mail.org> wrote:
        Joel Jacobson wrote:

> 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.

Looking at CopyReadLineText() over at [1], I don't see a reason why
the unquoted \. could not be handled with COPY FROM file.
Even COPY FROM STDIN looks like it could be benefit, so that
\copy from file csv would hopefully not choke or truncate the data.
There's still the case when the CSV data is embedded in a psql script
(psql is unable to know where it ends), but for that, "don't do that"
might be a reasonable answer.

Don't have what looks like a pg_dump script?
We specifically create such SQL files with embedded data.  Depending on the circumstances,
we either confirm that indexes dropped and triggers are disabled...  [Or we create a dynamic name,
and insert it into a queue table for later processing], and then we COPY the data, ending in
\.

We do NOT do "CSV", we mimic pg_dump.

Now, if you are talking about only impacting a fixed data file format... Sure.  But impacting how psql
processes these \i  included files...  (that could hurt)

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Avoiding another needless ERROR during nbtree page deletion
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction