Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Skip text->binary conversion of unnecessary columns in contrib/file_fdw.

  1. Unexpectedly exposed COPY option: convert_selectively

    Sugamoto Shinya <shinya34892@gmail.com> — 2026-02-16T06:55:29Z

    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

  2. Re: Unexpectedly exposed COPY option: convert_selectively

    KAZAR Ayoub <ma_kazar@esi.dz> — 2026-02-20T15:53:14Z

    Hello,

On Fri, Feb 20, 2026 at 3:19 AM Sugamoto Shinya <shinya34892@gmail.com>
wrote:

> 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.

For option 3, i don't see a use case other than one would want to have a
different option of selectively picking input fields to map them to a
subset of table columns, this is far from being similar to
convert_selectively implementation (as the first is more complex), so
option 1 seems like it.

> Regards,
> Shinya Sugamoto


Regards,
Ayoub