On Fri, May 2, 2025 at 11:37 PM David G. Johnston <david.g.johns...@gmail.com> wrote: > > On Friday, May 2, 2025, Masahiko Sawada <sawada.m...@gmail.com> wrote: >> >> >> I'm concerned about allowing multiple 'text' format implementations >> with identical names within the database, as this could lead to >> considerable confusion. When users specify 'text', it would be more >> logical to guarantee that the built-in 'text' format is consistently >> used. > > > Do you want to only give text/csv/binary this special treatment or also any > future format name we ever decide to implement in core. If an extension > takes up “xml” and we try to do that in core do we fail an upgrade because of > the conflict, and make it impossible to actually use said extension?
I guess that's an extension author's responsibility to upgrade its extension so as to work with the new PostgreSQL version, or carefully choose the format name. They can even name '[extension_name].[format_name]' as a format name. Even with the current patch design (i.e., search_path affects handler function lookups), users would end up using the built-in 'xml' format without notice after upgrade, no? I guess that could introduce another problem. 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. > >> This principle aligns with other customizable components, such >> as custom resource managers, wait events, lightweight locks, and >> custom scans. These components maintain their built-in data/types and >> explicitly prevent the registration of duplicate names. > > > I am totally lost on how any of those resemble this feature. > > 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? As I mentioned above, I think we need to keep backward compatibility but treating the built-in formats special seems inconsistent with common name resolution behavior. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
