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

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

In response to

Responses

Browse pgsql-hackers by date

  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