On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
> I mentioned that I planned to remove SELECT/CONNECT too.
> Now I've thought about it more and it seems to me that its better
> to keep them. As they give additional flexibility.
I very much like PL/Proxy and support your vision. Including the
features of PL/Proxy in core seems like a great idea to me.
If we have just a couple of commands, would it be easier to include
those features by some additional attributes on pg_proc? That way we
could include the features in a more native way, similar to the way we
have integrated text search, without needing a plugin language at all.
CREATE CLUSTER foo ...
CREATE FUNCTION bar() CLUSTER foo RUN ON ANY ...
If we did that, we might also include a similar proxy feature for
tables, making the feature exciting for more users than just those who
can specify implementing all logic through functions. It would also
remove the need for a specific SELECT command in PL/Proxy.
CREATE TABLE bar CLUSTER foo RUN ON ANY ...
If we're running a SELECT and all tables accessed run on the same
cluster we ship the whole SQL statement according to the RUN ON clause.
It would effectively bring some parts of dblink into core.
If all tables not on same cluster we throw an error in this release, but
in later releases we might introduce distributed join features and full
distributed DML support.
Having the PL/Proxy features available via the catalog will allow a
clear picture of what runs where without parsing the function text. It
will also allow things like a pg_dump of all objects relating to a
cluster.
Adding this feature for tables would be interesting with Hot Standby,
since it would allow you to offload SELECT statements onto the standby
automatically.
This would be considerably easier to integrate than text search was.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support