At Tue, 2 Aug 2022 14:17:46 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in
> Hi,
>
> On Tue, Aug 02, 2022 at 01:30:46PM +0900, Kyotaro Horiguchi wrote:
> > I noticed that COPY TO accepts FREEZE option but it is pointless.
> >
> > Don't we reject that option as the first-attached does?
>
> I agree that we should reject it, +1 for the patch.
Thanks for looking it!
> > 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.
>
> I also feel weird about it. I raised the same point recently about COPY FROM +
> HEADER MATCH (1), and at that time there wasn't a real consensus on the way to
> go, just keep the things consistent. I'm +0.5 on that patch for the same
> reason as back then. My only concern is that it can in theory break things if
> you rely on the current sqlstate, but given the errors I don't think it's
> really a problem.
Exactly. That is the exact reason for my to say "I'm not sure if..".
> [1]:
https://www.postgresql.org/message-id/flat/20220614091319.jk4he5migtpwyd7r%40jrouhaud#b18bf3705fb9f69d0112b6febf0fa1be
> Maybe that's just me but I understand "not supported" as "this makes
> sense, but this is currently a limitation that might be lifted
> later".
FWIW I understand it the same way.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
