Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO - Mailing list pgsql-hackers

From Richard Guo
Subject Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
Date
Msg-id CAMbWs48Z=Mnuuy2NU5J2=oeWOOR3hBg9sq2B0qhTauvf08xmiw@mail.gmail.com
Whole thread Raw
In response to Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
List 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

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: pg15 inherited stats expressions: cache lookup failed for statistics object
Next
From: Aleksander Alekseev
Date:
Subject: Re: Pluggable toaster