Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Zhang Mingli <zmlpostgres@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@postgresql.org
Date: 2022-11-01T09:51:42Z
Lists: 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
Commits
-
Remove code handling FORCE_NULL and FORCE_NOT_NULL for COPY TO
- 8e621c10c73a 16.0 landed
-
Add more tests for COPY with incorrect option combinations
- 451d1164b9d0 16.0 landed
-
Split copy.c into four files.
- c532d15dddff 14.0 cited