public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chao Li <[email protected]>
To: Masahiko Sawada <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: COPY: validate option presence rather than option values
Date: Mon, 29 Jun 2026 11:21:46 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAD21AoCsbjvgk5tOarepYF28dW7P6NG8SLVDQ72A7AJ3yEjriw@mail.gmail.com>
References: <[email protected]>
<CAD21AoCsbjvgk5tOarepYF28dW7P6NG8SLVDQ72A7AJ3yEjriw@mail.gmail.com>
> On Jun 27, 2026, at 05:09, Masahiko Sawada <[email protected]> wrote:
>
> On Tue, May 5, 2026 at 9:26 PM Chao Li <[email protected]> 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/
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: COPY: validate option presence rather than option values
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox