Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
Дата
Msg-id Y2DNm9u7hzIxCXHn@paquier.xyz
обсуждение исходный текст
Ответ на Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO  (Zhang Mingli <zmlpostgres@gmail.com>)
Ответы Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO  (Richard Guo <guofenglinux@gmail.com>)
Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO  (Mingli Zhang <zmlpostgres@gmail.com>)
Список pgsql-hackers
On Tue, Aug 02, 2022 at 04:13:30PM +0800, Zhang Mingli wrote:
> On Aug 2, 2022, 12:30 +0800, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, wrote:
>> There are some other option combinations that are rejected
>> by ProcessCopyOptions. On the other hand *re*checking all
>> combinations that the function should have rejected is kind of silly.
>> Addition to that, I doubt the assertions are really needed even though
>> the wrong values don't lead to any serious consequence.
>
> ProcessCopyOptions has rejected all invalid combinations and assertions are optional.

I agree with Horiguchi-san's point here: there is no real point in
having these assertions, especially just after the options are
processed.  A few extensions in-core (or even outside core) that I
know of, could call BeginCopyTo() or BeginCopyFrom(), but the option
processing is the same for all.

The point about cleaning up the attribute handling of FORCE_NOT_NULL
and FORCE_NULL in the COPY TO path is a good catch, though, so let's
remove all that.  I'll go apply this part of the patch in a bit, or
tomorrow.
--
Michael

Вложения

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Direct I/O
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Adding doubly linked list type which stores the number of items in the list