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 по дате отправления: