Re: Make COPY format extendable: Extract COPY TO format implementations
| От | David G. Johnston |
|---|---|
| Тема | Re: Make COPY format extendable: Extract COPY TO format implementations |
| Дата | |
| Msg-id | CAKFQuwaOPJPUeNGe5sFFYjR12XoawMnGODmi1jTxwJ9V5AjnDA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Make COPY format extendable: Extract COPY TO format implementations (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: Make COPY format extendable: Extract COPY TO format implementations
|
| Список | pgsql-hackers |
On Saturday, May 3, 2025, Masahiko Sawada <sawada.mshk@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 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”.
David J.
В списке pgsql-hackers по дате отправления: