From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] plproxy v2 |
Date: | 2008-07-08 15:43:38 |
Message-ID: | e51f66da0807080843p3b54ddc6nf0700a75a7d2c717@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/8/08, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> On Tue, 2008-07-08 at 10:21 +0100, Simon Riggs wrote:
> > On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
>
> > 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.
>
>
> > 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.
>
>
> First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
> think it needs to be in core. I wouldn't mind seeing it in contrib (or
> better yet modules/ should we ever get around to that).
I'm not against contrib/ considering that the docs are now nicely
integrated, but then, whats the difference between src/pl/ and contrib/?
OTOH, if you argue LANGUAGE plproxy vs. CREATE REMOTE FUNCTION,
then thats different matter. It seems to be we should do REMOTE FUNCTION
after, not before REMOTE TABLE as the table/view implementation
needs to dictate the actual details.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-07-08 15:52:54 | Re: [patch] plproxy v2 |
Previous Message | David Fetter | 2008-07-08 15:38:35 | Re: Exposing quals |