2013/11/27 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Seems to me that if you want to read remote tables without creating a
>> foreign table, you could define them locally using something like the
>> WITH syntax and then use them normally in the rest of the query.
>
> I guess what's needed here is a kind of barrier that allows pushing a
> whole arbitrary subquery (with joins and quals and whatnot) down to the
> remote side.
Yes, a big problem is how to skip parsing remote query in PG context.
Bare query string (other than string literal) always parsed by PG
parser, but remote side would have different syntax and semantics, as
Dimitri says we need to pass whole of arbitrary query string to remote
side as-is.
> My current thinking about how to solve that would be to add a notion of
> FOREIGN VIEW in our system, which would basically implement that barrier
> and send the view definition on the remote, with known quals values as
> constants, or something like that.
I'm sorry but I don't see the point here. Do you mean that user
executes CREATE FOREIGN VIEW in advance and uses the view in a
subsequent query? Or, allow new syntax like WITH alias AS FOREIGN VIEW
(remote query)?
I think it's nice to support executing ad-hoc remote query written in
the syntax which is valid only on remote data source through FDW, and
at the moment dblink interface seems feasible for that purpose.
--
Shigeru HANADA
