Re: Extensibility of the PostgreSQL wire protocol

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Extensibility of the PostgreSQL wire protocol
Date: 2021-02-22 18:01:00
Message-ID: 3598436.1614016860@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <jan(at)wi3ck(dot)info> writes:
> On 2/10/21 1:10 PM, Tom Lane 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".

> Those requests will naturally follow. But I don't see it as the main
> project's responsibility to satisfy them. It would be rather natural to
> develop the two things together. The same developer or group of
> developers, who are trying to connect a certain client, will want to
> have other compatibility features.

> As Jim Mlodgenski just posted in [0], having the ability to also extend
> and/or replace the parser will give them the ability to do just that.

Yeah, and as I pointed out somewhere upthread, trying to replace the
whole parser will just end in a maintenance nightmare. The constructs
that the parser has to emit are complex, Postgres-specific, and
constantly evolving. We are NOT going to promise any sort of cross
version compatibility for parse trees.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2021-02-22 18:13:32 Re: Extensibility of the PostgreSQL wire protocol
Previous Message Jacob Champion 2021-02-22 18:00:51 Re: Allow matching whole DN from a client certificate