From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pg <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE ROUTINE MAPPING |
Date: | 2018-01-18 21:09:13 |
Message-ID: | CADkLM=edk8dFDocuDLkoHMt79-wHy4ZA_Tec6vdXyr=gA++ZSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> >
> > But other situations seem un-handle-able to me:
> >
> > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
>
> Do we have any way, or any plan to make a way, to push the set (SELECT
> x FROM local_table WHERE active = true) to the remote side for
> execution there? Obviously, there are foreign DBs that couldn't
> support this, but I'm guessing they wouldn't have much by way of UDFs
> either.
>
No. The remote query has to be generated at planning time, so it can't make
predicates out of anything that can't be resolved into constants by the
planner itself. The complexities of doing so would be excessive, far better
to let the application developer split the queries up because they know
better which parts have to resolve first.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-01-18 21:28:28 | Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist |
Previous Message | Andres Freund | 2018-01-18 19:52:52 | Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)? |