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?
|
| Список | 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 по дате отправления: