From: | Jan Wieck <jan(at)wi3ck(dot)info> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 19:00:51 |
Message-ID: | dcfca070-e838-54b9-9e0c-71c4dbf8dab5@wi3ck.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/22/21 1:01 PM, Tom Lane wrote:
> 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.
Absolutely agreed. We cannot promise that the parsetree generated in one
version will work with the planner, optimizer and executor of the next.
These types of projects will need to pay close attention and more
importantly, develop their own regression test suites that detect when
something has changed in core. That said, discussion about the parser
hook should happen in the other thread.
I don't even expect that we can guarantee that the functions I am trying
to allow to be redirected for the wire protocol will be stable forever.
libpq V4 may need to change some of the call signatures, which has
happened before. For example, the function to send the command
completion message to the frontend (tcop/dest.c EndCommand()) changed
from 12 to 13.
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-02-22 19:48:25 | Re: libpq compression |
Previous Message | Jonah H. Harris | 2021-02-22 18:13:32 | Re: Extensibility of the PostgreSQL wire protocol |