Re: Extensibility of the PostgreSQL wire protocol

Поиск
Список
Период
Сортировка
От Joshua Drake
Тема Re: Extensibility of the PostgreSQL wire protocol
Дата
Msg-id CAJvJg-QJF5NjKWUfT2Stt-s0sHiqUrHCHwUwd38xMGgyhaSEEw@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 11:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> On Wed, Feb 10, 2021 at 1:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ...  If we start having
>> modes for MySQL identifier quoting, Oracle outer join syntax, yadda
>> yadda, it's going to be way more of a maintenance nightmare than some
>> hook functions.  So if we accept any patch along this line, I want to
>> drive a hard stake in the ground that the answer to that sort of thing
>> will be NO.

> Actually, a substantial amount can be done with hooks. For Oracle, which is
> substantially harder than MySQL, I have a completely separate parser that
> generates a PG-compatible parse tree packaged up as an extension. To handle
> autonomous transactions, database links, hierarchical query conversion,
> hints, and some execution-related items requires core changes.

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.

My feeling about this is if you want to use Oracle, go use Oracle.
Don't ask PG to take on a ton of maintenance issues so you can have
a frankenOracle.

PostgreSQL over the last decade spent a considerable amount of time allowing it to become extensible outside of core. We are now useful in workloads nobody would have considered in 2004 or 2008.

The more extensibility we add, the LESS we maintain. It is a lot easier to maintain an API than it is an entire kernel. When I look at all the interesting features coming from the ecosystem, they are all built on the hooks that this community worked so hard to create. This idea is an extension of that and a result of the community's success.

The more extensible we make PostgreSQL, the more the hacker community can innovate without damaging the PostgreSQL reputation as a rock solid database system.

Features like these only enable the entire community to innovate. Is the real issue that the more extensible PostgreSQL is, the more boring it will become?

JD

 

                        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Tightening up allowed custom GUC names