Re: CREATE ROUTINE MAPPING

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
>
>

In response to

Browse pgsql-hackers by date

  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