Re: CREATE ROUTINE MAPPING - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: CREATE ROUTINE MAPPING
Date
Msg-id CAFj8pRAcFbbO2Y0QEZth7KB3_auwuApFY379PgKpoO_cHvYp9Q@mail.gmail.com
Whole thread Raw
In response to Re: CREATE ROUTINE MAPPING  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers


2018-01-12 10:02 GMT+01:00 Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>:
On Fri, Jan 12, 2018 at 8:07 AM, Corey Huinker <corey.huinker@gmail.com> wrote:
> A few months ago, I was researching ways for formalizing calling functions
> on one postgres instance from another. RPC, basically. In doing so, I
> stumbled across an obscure part of the the SQL Standard called ROUTINE
> MAPPING, which is exactly what I'm looking for.
>
> The syntax specified is, roughly:
>
> CREATE ROUTINE MAPPING local_routine_name FOR remote_routine_spec
> SERVER my_server [ OPTIONS( ... ) ]
>
>
> Which isn't too different from CREATE USER MAPPING.
>
> The idea here is that if I had a local query:
>
> SELECT t.x, remote_func1(),  remote_func2(t.y)
>
> FROM remote_table t
>
> WHERE t.active = true;
>
>
> that would become this query on the remote side:
>
> SELECT t.x, local_func1(), local_func2(t.y)
>
> FROM local_table t
>
> WHERE t.active = true;
>

I think this is a desired feature. Being able to call a function on
remote server through local server is often useful.

PostgreSQL allows function overloading, which means that there can be
multiple functions with same name differing in argument types. So, the
syntax has to include the input parameters or their types at least.

+1

Pavel


--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [Sender Address Forgery]Re: [HACKERS] path toward fasterpartition pruning
Next
From: David Rowley
Date:
Subject: Re: [Sender Address Forgery]Re: [HACKERS] path toward fasterpartition pruning