Re: Extensibility of the PostgreSQL wire protocol
| От | Jonah H. Harris |
|---|---|
| Тема | Re: Extensibility of the PostgreSQL wire protocol |
| Дата | |
| Msg-id | CADUqk8X2s2PnnzXJxLCeoLP-8NAP7_ApXZgJBVg32g_6f7puGw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Extensibility of the PostgreSQL wire protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Wed, Feb 10, 2021 at 2:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
That is a spot-on definition of where I do NOT want to end up. Hooks
everywhere and enormous extensions that break anytime we change anything
in the core. It's not really clear that anybody is going to find that
more maintainable than a straight fork, except to the extent that it
enables the erstwhile forkers to shove some of their work onto the PG
community.
Given the work over the last few major releases to make several other aspects of Postgres pluggable, how is implementing a pluggable protocol API any different?
To me, this sounds more like a philosophical disagreement with how people could potentially use Postgres than a technical one. My point is only that, using current PG functionality, I could equally write a pluggable storage interface for my Oracle and InnoDB data file readers/writers, which would similarly allow for the creation of a Postgres franken-Oracle by extension only.
I don't think anyone is asking for hooks for all the things I mentioned - a pluggable transaction manager, for example, doesn't make much sense. But, when it comes to having actually done this vs. posited about its usefulness, I'd say it has some merit and doesn't really introduce that much complexity or maintenance overhead to core - whether the extensions still work properly is up to the extension authors... isn't that the whole point of extensions?
Jonah H. Harris
В списке pgsql-hackers по дате отправления: