| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: COPY: validate option presence rather than option values |
| Date: | 2026-06-29 03:21:46 |
| Message-ID: | 09E83EBC-66D3-4C35-9988-B7812A8D81FC@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jun 27, 2026, at 05:09, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Tue, May 5, 2026 at 9:26 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>
>> Hi,
>>
>> While testing COPY TO (FORMAT json), I noticed that the doc says FORCE_ARRAY is only allowed with FORMAT json:
>> ```
>> <varlistentry id="sql-copy-params-force-array">
>> <term><literal>FORCE_ARRAY</literal></term>
>> <listitem>
>> <para>
>> Force output of square brackets as array decorations at the beginning
>> and end of output, and commas between the rows. It is allowed only in
>> <command>COPY TO</command>, and only when using
>> <literal>json</literal> format. The default is
>> <literal>false</literal>.
>> </para>
>> </listitem>
>> </varlistentry>
>> ```
>>
>> However, this succeeds:
>> ```
>> evantest=# copy t1 to stdout (format csv, force_array false);
>> 1
>> ```
>>
>> So this is clearly validating the parsed value of force_array, rather than whether the option was specified at all.
>
> Hmm, I'm not sure this is actually a problem in practice. It seems
> straightforward to me that the documentation stating 'it is allowed
> only when...' can be interpreted as 'it is allowed to be enabled only
> when...'. My concern is that the proposed patch could make the command
> unnecessarily less flexible. This is especially true in cases where
> users programmatically generate a template COPY query and pass
> explicit boolean values (true/false) to the options. Also, other
> commands like VACUUM handle their boolean options in the exact same
> manner:
>
> =# vacuum (parallel 1, full) pg_class;
> ERROR: VACUUM FULL cannot be performed in parallel
> =# vacuum (parallel 1, full off) pg_class;
> VACUUM
>
> Regards,
>
> --
> Masahiko Sawada
> Amazon Web Services: https://aws.amazon.com
It seems there is no consistency even within the VACUUM command. BUFFER_USAGE_LIMIT is checked based on its presence, not its value:
```
evantest=# vacuum (full, BUFFER_USAGE_LIMIT 0) t;
ERROR: BUFFER_USAGE_LIMIT cannot be specified for VACUUM FULL
```
Here, 0 disables BUFFER_USAGE_LIMIT, but it is still not allowed when the option is not supposed to be used.
I posted a similar patch [1], and Fujii-san expressed the same opinion as you. So, let me withdraw both patches for now.
[1] https://www.postgresql.org/message-id/CD33AC99-0175-4AD9-A33F-88E57736DA8E%40gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-06-29 03:23:44 | Re: Reject HEADER with binary and json COPY formats by option presence |
| Previous Message | Richard Guo | 2026-06-29 03:01:16 | Re: plpython: NULL pointer dereference on broken sequence objects |