On Saturday, May 3, 2025, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, May 3, 2025 at 7:42 AM David G. Johnston > <david.g.johns...@gmail.com> wrote: > > > > On Saturday, May 3, 2025, Masahiko Sawada <sawada.m...@gmail.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.
