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 |
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 |