Re: COPY: validate option presence rather than option values

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/

In response to

Browse pgsql-hackers by date

  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