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
