Kyotaro Horiguchi <horikyota.ntt@xxxxxxxxx> writes: > At Thu, 09 Jan 2020 14:12:25 -0500, Tom Lane <tgl@xxxxxxxxxxxxx> wrote in >> 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. Hmm. It looks like that patch is moribund, and I can't say that I'm excited about reviving it. Aside from the syntactical reserved-word problems, it seems like a mighty heavyweight way of attacking the issue --- that is, instead of a property directly attached to the function of interest, you've now got this entire other system catalog structure that has to be searched for relevant information. And that needs all the usual support for a new object type, eg ALTER infrastructure, pg_dump support, etc etc etc. Plus, once you've created a mapping, it's only good for one server so you have to do it over again for each server. I guess in the general case you have to have that, but I'd sure want some kind of shortcut for the common case where e.g. ABS() means the same thing everywhere. The SQL committee do love verbosity, don't they. regards, tom lane
