Re: Make COPY format extendable: Extract COPY TO format implementations
От | David G. Johnston |
---|---|
Тема | Re: Make COPY format extendable: Extract COPY TO format implementations |
Дата | |
Msg-id | CAKFQuwauz43L0EtAmMz+OpQ0HWoongikc=Lnq2gZFM3cu_+cgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make COPY format extendable: Extract COPY TO format implementations (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Friday, March 28, 2025, Masahiko Sawada <sawada.mshk@gmail.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.
В списке pgsql-hackers по дате отправления: