Re: Make COPY format extendable: Extract COPY TO format implementations

On Saturday, May 3, 2025, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

> On Sat, May 3, 2025 at 7:42 AM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Saturday, May 3, 2025, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> >>
> >> I think that we need to ensure that if users specify text/csv/binary
> >> the built-in formats are always used, to keep backward compatibility.
> >
> >
> > That was my original thinking, but it’s inconsistent with how functions
> behave today. We don’t promise that installing extensions won’t cause
> existing code to change.
>
> I'm skeptical about whether that's an acceptable backward
> compatibility breakage.

I’m skeptical you are correctly defining what backward-compatibility
requires.

Well, the only potential breakage is that we are searching for a matching
function by signature without first limiting the mandated return type. But
that is solve-able should anyone else see the problem as well.

The global format name has its merits but neither it nor the namespaced
format option suffer from breaking compatibility or policy.

>
> I still don't fully understand why the FORMAT value alone needs to be
> treated like a schema-qualified object. If the concern is about name
> conflict with future built-in formats, I would argue that the same
> concern applies to custom EXPLAIN options and logical decoding
> plugins.

>
Then maybe we have the same “problem” in those places.

>
> To me, the benefit of treating the COPY FORMAT value as a
> schema-qualified object seems limited. Meanwhile, the risk of not
> protecting built-in formats like 'text', 'csv', and 'binary' is
> significant.

Really? You think lots of extensions are going to choose to use these
values even if they are permitted? Or are you concerned about attack
surfaces?

> If those names can be shadowed by extension via
> search_patch, we lose backward compatibility.
>

This is not a definition of backward-compatibility that I am familiar with.

If anything the ability for a DBA to arrange for such shadowing would be a
feature enhancement. They can drop-in a more efficient or desirable
implementation without having to change query code.

In any case, I’m doubtful either of us can make a convincing enough
argument to sway the other fully. Both options are plausible, IMO. Others
need to chime in.

David J.