[rfc,patch] PL/Proxy in core

Please consider this mail as submission of PL/Proxy into core.

Documentation:
https://developer.skype.com/SkypeGarage/DbProjects/PlProxy

Previous submission with overview:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01763.php

- The code has changed rather little compared to first submission,
biggest changes have been select()->poll() conversion and
making scanner work with flex 2.5.4.

- My interest in replacing dblink has decreased, it is for
-hackers to decide if this is interesting goal or not.

The patch itself:
http://plproxy.projects.postgresql.org/plproxy-v1.diff.gz

I have not much effort into patch, except made it compile
in with main source. I'd like to get general consensus that
the idea is acceptable first.

Following are major parts that need work before committing:

- SGML documentation.
- Makefile review.
- Integrate regression tests into main test framework.

There are 2 things that could be migrated in to core code,
but this can be done later:

- Compat poll() function based on select() - can be used to get
rid of #ifdef HAVE_POLL in various places in core code.

- rowstamp.h - all the PL-s could use it to detect row changes.

There are few code beautification ideas on which I'd like to
get feedback from wider audience:

- Drop CONNECT statement. This was added to make creating
simple dblink style calls easier, but actually its not
maintainable compared to CLUSTER, it can be used only
for occasional hacks. OTOH, if we want to deprecate
dblink and replace it with PL/Proxy, it should probably stay.

- Drop SELECT statement. This was added as it was simple to do
and also to be straightforward replacement for dblink. But
it's conceptually ugly. Also it gives impression that there
will be UPDATE, DELETE and IF... which will not happen.

The good developement strategy when using plproxy is:

1. Create regular database with function-based API,
keeping an eye that interfaces would support
partitioning.
2. If load grows, split database to several pieces,
directing clients to db where all functions are
plproxy ones which will rediect to correct
partition.

Having the SELECT available discourages good design
where all partitions are functional on their own.

--
marko

Diffstat for the patch:
src/include/catalog/pg_pltemplate.h | 1
src/pl/Makefile | 2
src/pl/plproxy/Makefile | 97 +++
src/pl/plproxy/cluster.c | 542 ++++++++++++++++++
src/pl/plproxy/execute.c | 750 +++++++++++++++++++++++++
src/pl/plproxy/expected/plproxy_clustermap.out | 71 ++
src/pl/plproxy/expected/plproxy_errors.out | 66 ++
src/pl/plproxy/expected/plproxy_init.out | 1
src/pl/plproxy/expected/plproxy_many.out | 116 +++
src/pl/plproxy/expected/plproxy_select.out | 37 +
src/pl/plproxy/expected/plproxy_test.out | 266 ++++++++
src/pl/plproxy/function.c | 408 +++++++++++++
src/pl/plproxy/main.c | 218 +++++++
src/pl/plproxy/parser.y | 190 ++++++
src/pl/plproxy/plproxy.h | 314 ++++++++++
src/pl/plproxy/poll_compat.c | 140 ++++
src/pl/plproxy/poll_compat.h | 58 +
src/pl/plproxy/query.c | 299 +++++++++
src/pl/plproxy/result.c | 222 +++++++
src/pl/plproxy/rowstamp.h | 27
src/pl/plproxy/scanner.l | 329 ++++++++++
src/pl/plproxy/sql/plproxy_clustermap.sql | 56 +
src/pl/plproxy/sql/plproxy_errors.sql | 63 ++
src/pl/plproxy/sql/plproxy_init.sql | 63 ++
src/pl/plproxy/sql/plproxy_many.sql | 66 ++
src/pl/plproxy/sql/plproxy_select.sql | 37 +
src/pl/plproxy/sql/plproxy_test.sql | 164 +++++
src/pl/plproxy/type.c | 308 ++++++++++
28 files changed, 4909 insertions(+), 2 modifications(!)