[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()
conversionand   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
maintainablecompared to CLUSTER, it can be used only for occasional hacks.  OTOH, if we want to deprecate dblink and
replaceit 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.
Butit'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            |    1src/pl/Makefile
  |    2src/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       |
1src/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
|  27src/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(!)