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

On Fri, May 2, 2025 at 11:37 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Friday, May 2, 2025, Masahiko Sawada <sawada.mshk@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
implementin 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
intoa 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