From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, guofenglinux(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO |
Date: | 2022-11-01 07:41:15 |
Message-ID: | Y2DNm9u7hzIxCXHn@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)ntt(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-11-01 07:55:37 | Re: Adding doubly linked list type which stores the number of items in the list |
Previous Message | Thomas Munro | 2022-11-01 07:36:18 | Direct I/O |