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
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 |