Re: Extensibility of the PostgreSQL wire protocol

From: Joshua Drake <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Extensibility of the PostgreSQL wire protocol
Date: 2021-02-11 18:28:57
Message-ID: CAJvJg-QJF5NjKWUfT2Stt-s0sHiqUrHCHwUwd38xMGgyhaSEEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 10, 2021 at 11:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> > On Wed, Feb 10, 2021 at 1:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-02-11 18:32:53 Re: Tightening up allowed custom GUC names
Previous Message Tom Lane 2021-02-11 17:51:52 Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)