Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: COPY: validate option presence rather than option values
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAD21AoCsbjvgk5tOarepYF28dW7P6NG8SLVDQ72A7AJ3yEjriw@mail.gmail.com>
Date: Mon, 29 Jun 2026 11:21:46 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <09E83EBC-66D3-4C35-9988-B7812A8D81FC@gmail.com>
References: <C1D2509E-E5D1-46B0-932C-B57AA7B963A1@gmail.com>
 <CAD21AoCsbjvgk5tOarepYF28dW7P6NG8SLVDQ72A7AJ3yEjriw@mail.gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/09E83EBC-66D3-4C35-9988-B7812A8D81FC%40gmail.com>
Precedence: bulk


> On Jun 27, 2026, at 05:09, Masahiko Sawada <sawada.mshk@gmail.com> =
wrote:
>=20
> On Tue, May 5, 2026 at 9:26=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>> Hi,
>>=20
>> While testing COPY TO (FORMAT json), I noticed that the doc says =
FORCE_ARRAY is only allowed with FORMAT json:
>> ```
>>   <varlistentry id=3D"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>
>> ```
>>=20
>> However, this succeeds:
>> ```
>> evantest=3D# copy t1 to stdout (format csv, force_array false);
>> 1
>> ```
>>=20
>> So this is clearly validating the parsed value of force_array, rather =
than whether the option was specified at all.
>=20
> 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:
>=20
> =3D# vacuum (parallel 1, full) pg_class;
> ERROR:  VACUUM FULL cannot be performed in parallel
> =3D# vacuum (parallel 1, full off) pg_class;
> VACUUM
>=20
> Regards,
>=20
> --=20
> 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=3D# 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/