an
backdoor anybody else's usage of this server".
I see that SQL:2011's access rules for "CREATE ROUTINE MAPPING" are
1) The applicable privileges shall include the USAGE privilege on
the foreign server identified by FSN.
2) Additional privileges, if
On Mon, Sep 10, 2018 at 09:28:31AM +0200, Hannu Krosing wrote:
> Hi Corey
>
> Have you looked at pl/proxy ?
DBI-Link pre-dated PL/proxy by some years, and was a good bit more
flexible as to what types of functions it could send where. Neither
has a capability fundamentally similar to this because
nc() is invoked in local because the col1
>> >> column of local_table is referenced by it.
>
> Do you mean that ISO/IEC 9075-9:2016 (right?) is defining that
> (and we must follow it)? Or does it comes by referring to
> something like [1]? As far as I see David's mail
On Mon, Sep 10, 2018 at 3:28 AM Hannu Krosing
wrote:
> Hi Corey
>
> Have you looked at pl/proxy ?
>
I have, a long while ago.
> It does this and then some (sharding)
>
PL/proxy isn't a part of the SQL Standard.
PL/proxy only connects to other libpq-speaking databases.
The hope with routine ma
tly 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
l_func() is invoked in local because the col1
> >> column of local_table is referenced by it.
Do you mean that ISO/IEC 9075-9:2016 (right?) is defining that
(and we must follow it)? Or does it comes by referring to
something like [1]? As far as I see David's mail upthread,
OPTIONS is not
so interested in this feature. While studying this feature, I
>> understood that this feature just pair a local function with a remote
>> function, not means that creates a kind of virtual function that can
>> be invoked on only foreign servers. For example, if we execute the
ollowing routine mapping,
>
> CREATE ROUTINE MAPPING rmap FOR local_func(integer) OPTIONS
> (remote_func_schema = 'myschema', remote_func_name = 'remote_func');
>
> and execute the similar SQL for a foreign table. We will get the
> following remote SQL.
>
ns that creates a kind of virtual function that can
be invoked on only foreign servers. For example, if we execute the
following SQL the local_func() is invoked in local because the col1
column of local_table is referenced by it.
SELECT * FROM local_table l WHERE local_func(l.col1) = 1;
On th
On Thu, Jan 25, 2018 at 10:43 AM, David Fetter wrote:
> On Thu, Jan 18, 2018 at 04:09:13PM -0500, Corey Huinker wrote:
>> >
>> >
>> > >
>> > > But other situations seem un-handle-able to me:
>> > >
>> > > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
>> >
>> > Do we have any w
On Thu, Jan 18, 2018 at 04:09:13PM -0500, Corey Huinker wrote:
> >
> >
> > >
> > > But other situations seem un-handle-able to me:
> > >
> > > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
> >
> > Do we have any way, or any plan to make a way, to push the set (SELECT
> > x FROM
>
>
> >
> > But other situations seem un-handle-able to me:
> >
> > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
>
> Do we have any way, or any plan to make a way, to push the set (SELECT
> x FROM local_table WHERE active = true) to the remote side for
> execution there? Obvi
On Wed, Jan 17, 2018 at 11:09:19AM -0500, Corey Huinker wrote:
> > > CREATE ROUTINE MAPPING local_routine_name
> > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [
> > argname ]
> > > > argtype [ { DEFAULT | = } default_expr ] [
> > CREATE ROUTINE MAPPING local_routine_name
> > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [
> argname ]
> > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
> > >[ RETURNS rettype
> > > | RETURNS TABLE ( col
On Fri, Jan 12, 2018 at 02:29:53PM -0500, Corey Huinker wrote:
> >
> >
> >
> > 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 b
>
>
>
> 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.:
>
> CREATE ROUTINE MAPPING local_routine_name
> FOR (FUNCTION | PROCEDURE) r
which leaves only one other
> place to define it, remote_routine_spec, which wasn't defined at
> all. I _suppose_ parameter definitions could be pushed into options,
> but that'd be ugly.
In my draft of SQL:2011, which I don't think has substantive changes
to what
>
> 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.
>
"local_routine_name" and "remote_routine_spec" were my own paraphrasings of
wha
d 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 [ OPT
NG, 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
> 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( ... ) ]
[neat use cases elided]
For what it's worth, the now-defunct DBI-Link I
ughly:
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.act
22 matches
Mail list logo
