Re: COPY TO (FREEZE)?

On Tue, Aug 2, 2022 at 05:17:35PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 2 Aug 2022 14:17:46 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)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.

I would like to apply the attached patch to master. Looking at your
adjustments for ERRCODE_FEATURE_NOT_SUPPORTED to
ERRCODE_INVALID_PARAMETER_VALUE, I only changed the cases where it would
be illogical to implement the feature, not just that we have no
intention of implementing the feature. I read "invalid" as "illogical".

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.