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 all for registration to enable additional options and features - but >> > am against moving away from turning format into a namespaced identifier. >> > This is a query-facing feature where namespaces are common and >> > fundamentally required. >> >> That's a fair concern. But isn't the format name ultimately just an >> option value, but not like a database object? > > > We get to decide that. And deciding in favor of “extensible database object > in a namespace’ makes more sense - leveraging all that pre-existing design to > play more nicely with extensions and give DBAs control. The SQL command to > add one is “create function” instead of “create copy format”. 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. 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. If those names can be shadowed by extension via search_patch, we lose backward compatibility. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
