COPY TO (FREEZE)?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: COPY TO (FREEZE)?
Date: 2022-08-02 04:30:46
Message-ID: 20220802.133046.1941977979333284049.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed that COPY TO accepts FREEZE option but it is pointless.

Don't we reject that option as the first-attached does? I tempted to
add tests for those option combinations that are to be rejected but I
didin't come up with a clean way to do that.

By the way, most of the invalid option combinations for COPY are
marked as ERRCODE_FEATURE_NOT_SUPPORTED. I looks to me saying that
"that feature is theoretically possible or actually realized
elsewhere, but impossible now or here".

If it is correct, aren't they better be ERRCODE_INVALID_PARAMETER_VALUE? The code is being used for similar messages "unrecognized parameter <name>" and "parameter <name> specified more than once" (or some others?). At least a quote string longer than a single character seems like to fit INVALID_PARAMETER_VALUE. (I believe we don't mean to support multicharacter (or even multibyte) escape/quote character anddelimiter). That being said, I'm not sure if the change will be worth the trouble.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
reject_COPY_TO_FREEZE.patch text/x-patch 1.2 KB
change_some_errcodes.patch text/x-patch 4.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-08-02 04:30:50 Re: [Refactor]Avoid to handle FORCE_NOT_NULL/FORCE_NULL options when COPY TO
Previous Message Nathan Bossart 2022-08-02 04:29:33 Re: allow building trusted languages without the untrusted versions