Re: [Proposal] Arbitrary queries in postgres_fdw

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rtorre(at)carto(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Proposal] Arbitrary queries in postgres_fdw
Date: 2019-10-25 16:38:05
Message-ID: 19101.1572021485@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

rtorre(at)carto(dot)com writes:
> We stumbled upon a few cases in which retrieving information from the
> foreign server may turn pretty useful before creating any foreign
> table, especially info related to the catalog. E.g: a list of schemas
> or tables the user has access to.

> I thought of using dblink for it, but that requires duplication of
> server and user mapping details and it adds its own management of
> connections.

> Then I thought a better approach may be a mix of both: a function to
> issue arbitrary queries to the foreign server reusing all the details
> encapsulated in the server and user mapping. It would use the same
> pool of connections.

dblink can already reference a postgres_fdw "server" for connection
details, so I think this problem is already solved from the usability
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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-25 16:46:57 Re: vacuum on table1 skips rows because of a query on table2
Previous Message Tom Lane 2019-10-25 16:28:38 Re: segmentation fault when cassert enabled