Re: New "single" COPY format

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: New "single" COPY format
Date: 2024-11-08 06:02:34
Message-ID: 74eeb70e-6e55-4692-ba66-21a7bb1aa11a@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 8, 2024, at 00:13, Masahiko Sawada wrote:
> In earlier versions, we supported loading the whole file into a single
> tuple. Is there any reason that it doesn't support it in v18? I think
> if it's useful we can improve it in a separate patch.

Not sure how useful it is, since we already have pg_read_file().

Also, I think it's out of scope for the 'single' format, since I think it should
be about about processing text line by line, in the same way 'csv' and 'text'
work.

The implementation depended on the delimiter option, where the default was
no delimiter, which then read the entire file, and since we don't have
the delimiter option anymore, that approach won't work.

From a docs perspective, it would get quite ugly and confusing, since we would
need to rephrase sentences like the below, since they would then not always
be true:

"each line is treated as a single field"

"each line of the input or output is considered a
complete value without any field separation"

>> * A final EOL is now emitted to the last record in COPY TO.
>> So now it works just like 'text' and 'csv'.
>>
>
> +1
>
>> * HEADER [ boolean | MATCH ] now supported
>> This is now again supported, as previously suggested by Daniel Verite,
>> possible thanks to the EOL handling.
>
> It makes sense to support it.

/Joel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2024-11-08 06:05:04 Re: Expand applicability of aggregate's sortop optimization
Previous Message Michael Paquier 2024-11-08 05:34:34 Re: define pg_structiszero(addr, s, r)