Jan Wieck <j...@wi3ck.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
