Re: Extensibility of the PostgreSQL wire protocol

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

In response to

Browse pgsql-hackers by date

  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