From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pg <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE ROUTINE MAPPING |
Date: | 2018-01-12 09:57:33 |
Message-ID: | CAFj8pRAcFbbO2Y0QEZth7KB3_auwuApFY379PgKpoO_cHvYp9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2018-01-12 10:02 GMT+01:00 Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>:
> On Fri, Jan 12, 2018 at 8:07 AM, Corey Huinker <corey(dot)huinker(at)gmail(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-01-12 09:58:32 | Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning |
Previous Message | Amit Langote | 2018-01-12 09:51:20 | Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning |