Skip site navigation (1) Skip section navigation (2)

[patch] plproxy v2

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: [patch] plproxy v2
Date: 2008-06-28 13:36:02
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
We have written a FAQ, where are common issues collected, there
are also discussion about design decisions and why concentrating
only to functions is good idea.

The patch itself is attached, and also made available here:

Changes since v1:
- dynamic record patch from Lei Yonghua.  That makes functions
  that require result types specified with AS clause work.
- accepts int2/4/8 from hash function
- removed get_cluster_config()
- draft sgml documentation
- disabled binary I/O by default.

- parser.y: remove use of alloca, define malloc/free to palloc/pfree
- scanner.l: fix crash if palloc() throws exception by reinitializing
  flex properly
- make installcheck work
- removed backwards compat code
- use bool instead bitfields to conform to Postgres coding style.

- the docs should be more fleshed out
- should regtest moved to src/test/regress?
- make GUC vars for binary i/o and connection_lifetime?

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.

CONNECT - allows to test plproxy without creating plproxy schema.
Good for quick hacks, RPC-s.  Main problem is that as soon
user starts to have several environments - dev/test/live -
he will get hurt, but that could be solved by giving suggestions
in docs how to avoid that. Eg. suggest using service= or fake hostnames.

SELECT - main reason to keep it would be to allow calling
different functions, having different argument/result names
or types.


Attachment: plproxy-v2.diff.gz
Description: application/x-gzip (33.9 KB)


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-06-28 14:48:04
Subject: Re: stat() vs cygwin
Previous:From: Magnus HaganderDate: 2008-06-28 13:34:32
Subject: Re: pgsql: Make the pg_stat_activity view call a SRF

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group