Re: SQL/MED with simple wrappers

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED with simple wrappers
Date: 2010-10-25 13:05:51
Message-ID: AANLkTingUR2OEBdh3syXdfefdSm+RYt48iTYxSPY7TEs@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

> 4) List of foreign connections
> Users (especially DBAs?) might want to see list of foreign connections.
> Currently postgresql_fdw provides its own connection list via
> postgresql_fdw_connections view.  Common view such as
> pg_foreign_connections would be needed?  If so, function which returns
> list of active connections would be necessary in FDW API.
>

+ list of foreign tables?

> 5) Routine mapping
> If a function in local query can be evaluated on the remote side in
> same semantics, it seems efficient to push the function down to the
> remote side.  But how can we know whether the function can be pushed
> down or not?  For such purpose, SQL/MED standard defines "routine
> mapping".  Should we implement routine mapping?
>

is it related to aggregate functions? If yes, this it can be really
significant help

>
> 7) Using cursor in postgresql_fdw
> postgresql_fdw fetches all of the result tuples from the foreign
> server in the first pgIterate() call.  It could cause out-of-memory if
> the result set was huge.  If libpq supports protocol-level cursor,
> postgresql_fdw will be able to divide result set into some sets and
> lower the usage of memory.  Or should we use declare implicit cursor
> with DECLARE statement?  One connection can be used by multiple
> ForeignScan nodes in a local query alternately.  An issue is that
> cursor requires implicit transaction block.  Is it OK to start
> transaction automatically?

I don't know why DECLARE statement is problem? Can you explain it, please.

regards

Pavel Stehule

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-10-25 13:33:04 Re: find -path isn't portable
Previous Message KaiGai Kohei 2010-10-25 12:51:28 Re: security hook on authorization