Unexpectedly exposed COPY option: convert_selectively

Hi, everyone.

I’d like to discuss a COPY option, convert_selectively. It appears to
have been intended as an internal (non-SQL-exposed) option, but it can
currently be specified via the SQL COPY syntax.

This option was introduced in commit a36088bcfae to improve
performance of contrib/file_fdw by converting only the required
columns, rather than converting all column data. The comment in
src/backend/commands/copy.c (around L696–L700) says it is
“Undocumented, not accessible from SQL”, i.e., not intended to be
specified as a COPY option:

```
/*
* Undocumented, not-accessible-from-SQL option: convert only the
* named columns to binary form, storing the rest as NULLs. It's
* allowed for the column list to be NIL.
*/
```

However, as I pointed out in this thread, it can be specified from SQL:

https://www.postgresql.org/message-id/CAAe3y%2B85VpE860m%2BT0m2LzKQWnZ_r6FzO1_1ZNSixYP5F24ahg%40mail.gmail.com

Here is a reproduction:

```sql
CREATE TABLE conv_test (
a int,
b int,
c text
);

COPY conv_test FROM STDIN (
FORMAT csv,
convert_selectively (a, b)
);

-- STDIN data:
1,2,foo
3,4,bar

SELECT * FROM conv_test;
```

Result:
```
a | b | c
---+---+------
1 | 2 | NULL
3 | 4 | NULL
(2 rows)
```

Given this, I’m considering one of the following changes:
Option 1: Update the comment to match the current behavior.
Option 2: Change the behavior to reject convert_selectively when
specified via SQL COPY.
Option 3: Officially support and document the convert_selectively option.

My preference is Option 1, since it’s the simplest change and, as far
as I know, there are no user-facing issues today. Option 2 would be a
backward-incompatible change (even if undocumented). Option 3 would
require additional work to make it a supported and documented feature,
and I’m not aware of a clear demand/use case yet.

Please let me know if you have any opinions. If there are no
objections, I plan to proceed with updating the comment.

Regards,
Shinya Sugamoto