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 | CAKFQuwZbD_=-Htfv1CjuhcXjTtG-xdCYrjUa4Yi7tVHEHnhorA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Make COPY format extendable: Extract COPY TO format implementations (jian he <jian.universality@gmail.com>) |
| Список | pgsql-hackers |
On Sun, Apr 6, 2025 at 4:30 AM jian he <jian.universality@gmail.com> wrote:
CREATE FUNCTION test_copy_format(internal)
RETURNS copy_handler
AS 'MODULE_PATHNAME', 'test_copy_format'
LANGUAGE C;
src/backend/commands/copy.c: ProcessCopyOptions
if (strcmp(fmt, "text") == 0)
/* default format */ ;
else if (strcmp(fmt, "csv") == 0)
opts_out->csv_mode = true;
else if (strcmp(fmt, "binary") == 0)
opts_out->binary = true;
else
{
List *qualified_format;
....
}
what if our customized format name is one of "csv", "binary", "text",
then that ELSE branch will never be reached.
then our customized format is being shadowed?
Yes. The user of your extension can specify a schema name to get access to your conflicting format name choice but all the existing code out there that relied on text/csv/binary being the built-in options continue to behave the same no matter the search_path.
David J.
В списке pgsql-hackers по дате отправления: