It goes on from there, but I think there's a reasonable interpretation of this which allows us to use the same syntax as CREATE (FUNCTION|PROCEDURE), apart from the body, e.g.:
That's really interesting. I didn't think to look in the definition of CREATE FUNCTION to see if a SERVER option popped in there, but seems like a more accessible way to introduce the notion of remote functions, because I talked to a few developers about this before posting to the list, and only one had ever heard of ROUTINE MAPPING and had no clear recollection of it. An option on CREATE FUNCTION is going to get noticed (and used!) a lot sooner.
Having said that, I think syntactically we have to implement CREATE ROUTINE MAPPING, even if it is just translated to a CREATE FUNCTION call.
In either case, I suspected that pg_proc would need a nullable srvid column pointing to pg_foreign_server, and possibly a new row in pg_language for 'external'. I had entertained having a pg_routine_mappings table like pg_user_mappings, and we still could, if the proc's language of 'external' clued the planner to look for the mapping. I can see arguments for either approach.
Before anyone asks, I looked for, and did not find, any suggestion of IMPORT FOREIGN ROUTINE a la IMPORT FOREIGN SCHEMA, so as of yet there wouldn't be any way to grab all the functions that .a foreign server is offering up.
