Re: Extensibility of the PostgreSQL wire protocol

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-10 18:42:26
Message-ID: CADUqk8W=VaPtmA1TXJoCCHZDm-jMK+noYZ+rHQ0m24Wv3MV0bQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> What I'm actually more concerned about, in this whole line of development,
> is the follow-on requests that will surely occur to kluge up Postgres
> to make its behavior more like $whatever. As in "well, now that we
> can serve MySQL clients protocol-wise, can't we pretty please have a
> mode that makes the parser act more like MySQL". 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. But, the
protocol and parsing can definitely be done with hooks. And, as was
mentioned previously, this isn't tied directly to emulating another
database - it would enable us to support an HTTP-ish interface directly in
the server as an extension as well. A lot of this can be done with
background worker extensions now, which is how my stuff was primarily
architected, but it's hacky when it comes to areas where the items Jan
discussed could clean things up and make them more pluggable.

Assuming we're going to keep to that, though, it seems like people
> doing this sort of thing will inevitably end up with a fork anyway.
> So maybe we should just not bother with the first step either.
>

Perhaps I'm misunderstanding you, but I wouldn't throw this entire idea out
(which enables a substantial addition of extensible functionality with a
limited set of touchpoints) on the premise of future objections.

--
Jonah H. Harris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-02-10 19:04:29 Re: Extensibility of the PostgreSQL wire protocol
Previous Message Joel Jacobson 2021-02-10 18:34:23 Re: [HACKERS] GSoC 2017: Foreign Key Arrays