Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
От | Richard Guo |
---|---|
Тема | Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO |
Дата | |
Msg-id | CAMbWs48Z=Mnuuy2NU5J2=oeWOOR3hBg9sq2B0qhTauvf08xmiw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
|
Список | pgsql-hackers |
On Tue, Nov 1, 2022 at 3:41 PM Michael Paquier <michael@paquier.xyz> wrote:
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.
I'm OK with not having these assertions. I have to admit they look
somewhat redundant here, after what ProcessCopyOptions has done.
Thanks
Richard
somewhat redundant here, after what ProcessCopyOptions has done.
Thanks
Richard
В списке pgsql-hackers по дате отправления: