Re: Make COPY format extendable: Extract COPY TO format implementations

On Friday, March 28, 2025, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
>
> One problem in the following chunk I can see is:
>
> + qualified_format = stringToQualifiedNameList(format, NULL);
> + DeconstructQualifiedName(qualified_format, &schema, &fmt);
> + if (!schema || strcmp(schema, "pg_catalog") == 0)
> + {
> + if (strcmp(fmt, "csv") == 0)
> + opts_out->csv_mode = true;
> + else if (strcmp(fmt, "binary") == 0)
> + opts_out->binary = true;
> + }
>
> Non-qualified names depend on the search_path value so it's not
> necessarily a built-in format. If the user specifies 'csv' with
> seach_patch = 'myschema, pg_catalog', the COPY command unnecessarily
> sets csv_mode true. I think we can instead check if the retrieved
> handler function's OID matches the built-in formats' ones. Also, it's
> weired to me that cstate has csv_mode and binary fields even though
> the format should have already been known by the callback functions.
>

I considered it a feature that a schema-less reference to text, csv, or
binary always resolves to the core built-in handlers. As does an
unspecified format default of text.

To use an extension that chooses to override that format name would require
schema qualification.

David J.