Re: PostgreSQL <-> Babelfish integration

On Fri, 12 Feb 2021 at 19:44, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Fri, Feb 12, 2021 at 10:26 AM Álvaro Hernández <aht(at)ongres(dot)com> wrote:
> > As I stated in the mentioned post, I believe Babelfish is a very
> > welcomed addition to the PostgreSQL ecosystem. It allows PostgreSQL to
> > reach other users, other use cases, other markets; something which in my
> > opinion PostgreSQL really needs to extend its reach, to become a more
> > relevant player in the database market. The potential is there,
> > specially given all the extensibility points that PostgreSQL already
> > has, which are unparalleled in the industry.
>
> Let's assume for the sake of argument that your analysis of the
> benefits is 100% correct -- let's take it for granted that Babelfish
> is manna from heaven. It's still not clear that it's worth embracing
> Babelfish in the way that you have advocated.
>
> We simply don't know what the costs are. Because there is no source
> code available. Maybe that will change tomorrow or next week, but as
> of this moment there is simply nothing substantive to evaluate.

I agree. I believe that Babelfish's efforts can be compared with the
zedstore and zheap efforts: they require work in core before they can
be integrated or added as an extension that could replace the normal
heap tableam, and while core is being prepared we can discover what
can and cannot be prepared in core for this new feature. But as long
as there is no information about what structural updates in core would
be required, no commitment can be made for inclusion. And although I
would agree that an extension system for custom protocols and parsers
would be interesting, I think it would be putting the cart before the
horse if you want to force a decision 4 years ahead of time [0],
without ever having seen the code or even a design document.

In general, I think postgres could indeed benefit from a pluggable
protocol and dialect frontend, but as long as there are no public and
open projects that demonstrate the benefits or would provide a guide
for implementing such frontend, I see no reason for the postgres
project to put work into such a feature.

With regards,

Matthias van de Meent

[0] I believe this is an optimistic guess, based on the changes that
were (and are yet still) required for the zedstore and/or zheap
tableam, but am happy to be proven wrong.