Re: Make COPY format extendable: Extract COPY TO format implementations - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Make COPY format extendable: Extract COPY TO format implementations
Date
Msg-id CAKFQuwZbD_=-Htfv1CjuhcXjTtG-xdCYrjUa4Yi7tVHEHnhorA@mail.gmail.com
Whole thread Raw
In response to Re: Make COPY format extendable: Extract COPY TO format implementations  (jian he <jian.universality@gmail.com>)
List 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 by date:

Previous
From: Mahendra Singh Thalor
Date:
Subject: Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
Next
From: Alexander Korotkov
Date:
Subject: Re: Removing unneeded self joins