At Thu, 09 Jan 2020 14:12:25 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Stephen Frost <sfrost@snowman.net> writes:
> > I agree with all of that- but it seems like we've got people asking for
> > it, and I can understand why they are, and therefore I'd be inclined to
> > provide a way for users to get that behavior and I'm even inclined to
> > say that pushing down should be the 'default' if everything else is
> > equal and it's possible to do so.
>
> [ shrug... ] I think that's a completely arbitrary value judgment
> unsupported by any facts. Furthermore, it'd greatly expand our exposure
> to problems with "we thought this function behaves the same on the remote
> end, but it doesn't". That hazard makes me feel that the default should
> *never* be to encourage pushing down, unless there's a pretty clear
> potential win to justify the risk of breakage.
>
> If SQL/MED has a notion of a "foreign function" that is only executable on
> the remote side, and that fails if you try to execute it locally, then
> it'd make sense to implement that feature and then expect postgres_fdw to
> try hard to push down such calls. But we don't have that (yet). I'm
> unconvinced that ordinary functions ought to be treated as if remote
> execution is preferable.
Isn't ROUTING MAPPING [1] that? Definers should define one at their
own risk as table constraints are.
[1] https://www.postgresql.org/message-id/CAD21AoCSzZO%2Bd3EL-9w%3D97aC28%3DRb3%2BBh77wRLcP7HCH8-Bn9A%40mail.gmail.com
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center