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

Поиск
Список
Период
Сортировка
От Sutou Kouhei
Тема Re: Make COPY format extendable: Extract COPY TO format implementations
Дата
Msg-id 20240112.144615.157925223373344229.kou@clear-code.com
обсуждение исходный текст
Ответ на Re: Make COPY format extendable: Extract COPY TO format implementations  (Sutou Kouhei <kou@clear-code.com>)
Ответы Re: Make COPY format extendable: Extract COPY TO format implementations  (Sutou Kouhei <kou@clear-code.com>)
Список pgsql-hackers
Hi,

Here is the current summary for a this discussion to make
COPY format extendable. It's for reaching consensus and
starting implementing the feature. (I'll start implementing
the feature once we reach consensus.) If you have any
opinion, please share it.

Confirmed:

1.1 Making COPY format extendable will not reduce performance.
    [1]

Decisions:

2.1 Use separated handler for COPY TO and COPY FROM because
    our COPY TO implementation (copyto.c) and COPY FROM
    implementation (coypfrom.c) are separated.
    [2]

2.2 Don't use system catalog for COPY TO/FROM handlers. We can
    just use a function(internal) that returns a handler instead.
    [3]

2.3 The implementation must include documentation.
    [5]

2.4 The implementation must include test.
    [6]

2.5 The implementation should be consist of small patches
    for easy to review.
    [6]

2.7 Copy{To,From}State must have a opaque space for
    handlers.
    [8]

2.8 Export CopySendData() and CopySendEndOfRow() for COPY TO
    handlers.
    [8]

2.9 Make "format" in PgMsg_CopyOutResponse message
    extendable.
    [9]

2.10 Make makeNode() call avoidable in function(internal)
     that returns COPY TO/FROM handler.
     [9]

2.11 Custom COPY TO/FROM handlers must be able to parse
     their options.
     [11]

Discussing:

3.1 Should we use one function(internal) for COPY TO/FROM
    handlers or two function(internal)s (one is for COPY TO
    handler and another is for COPY FROM handler)?
    [4]

3.2 If we use separated function(internal) for COPY TO/FROM
    handlers, we need to define naming rule. For example,
    <method_name>_to(internal) for COPY TO handler and
    <method_name>_from(internal) for COPY FROM handler.
    [4]

3.3 Should we use prefix or suffix for function(internal)
    name to avoid name conflict with other handlers such as
    tablesample handlers?
    [7]

3.4 Should we export Copy{To,From}State? Or should we just
    provide getters/setters to access Copy{To,From}State
    internal?
    [10]


[1] https://www.postgresql.org/message-id/flat/20231204.153548.2126325458835528809.kou%40clear-code.com
[2] https://www.postgresql.org/message-id/flat/ZXEUIy6wl4jHy6Nm%40paquier.xyz
[3] https://www.postgresql.org/message-id/flat/CAD21AoAhcZkAp_WDJ4sSv_%2Bg2iCGjfyMFgeu7MxjnjX_FutZAg%40mail.gmail.com
[4] https://www.postgresql.org/message-id/flat/CAD21AoDkoGL6yJ_HjNOg9cU%3DaAdW8uQ3rSQOeRS0SX85LPPNwQ%40mail.gmail.com
[5]
https://www.postgresql.org/message-id/flat/TY3PR01MB9889C9234CD220A3A7075F0DF589A%40TY3PR01MB9889.jpnprd01.prod.outlook.com
[6] https://www.postgresql.org/message-id/flat/ZXbiPNriHHyUrcTF%40paquier.xyz
[7] https://www.postgresql.org/message-id/flat/20231214.184414.2179134502876898942.kou%40clear-code.com
[8] https://www.postgresql.org/message-id/flat/20231221.183504.1240642084042888377.kou%40clear-code.com
[9] https://www.postgresql.org/message-id/flat/ZYTfqGppMc9e_w2k%40paquier.xyz
[10] https://www.postgresql.org/message-id/flat/CAD21AoD%3DUapH4Wh06G6H5XAzPJ0iJg9YcW8r7E2UEJkZ8QsosA%40mail.gmail.com
[11] https://www.postgresql.org/message-id/flat/20240110.152023.1920937326588672387.kou%40clear-code.com


Thanks,
-- 
kou



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Synchronizing slots from primary to standby
Следующее
От: torikoshia
Дата:
Сообщение: doc: add LITERAL tag to RETURNING