Re: [Proposal] Arbitrary queries in postgres_fdw

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: rtorre(at)carto(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Proposal] Arbitrary queries in postgres_fdw
Date: 2019-10-28 12:53:58
Message-ID: CA+TgmoZqYPmUN1FygNuGBiJawgko8JNATZ1YpEghWEUPCAWSTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 25, 2019 at 12:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> end of things. And allowing arbitrary queries to go over a postgres_fdw
> connection would be absolutely disastrous from a debuggability and
> maintainability standpoint, because they might change the remote
> session's state in ways that postgres_fdw isn't prepared to handle.
> (In a dblink connection, the remote session's state is the user's
> responsibility to manage, but this isn't the case for postgres_fdw.)
> So I think this proposal has to be firmly rejected.

I think the reduction in debuggability and maintainability has to be
balanced against a possible significant gain in usability. I mean,
you could document that if the values of certain GUCs are changed, or
if you create and drop prepared statements with certain names, it
might cause queries in the same session issued through the regular
foreign table API to produce wrong answers. That would still leave an
enormous number of queries that users could issue with absolutely no
problems. I really don't see a bona fide maintainability problem here.
When someone produces a reproducible test case showing that they did
one of the things we told them not to do, then we'll tell them to read
the fine manual and move on.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-10-28 13:05:40 Re: Add const qualifiers to internal range type APIs
Previous Message Peter Eisentraut 2019-10-28 12:52:02 Preserve versions of initdb-created collations in pg_upgrade