On Tue, 2008-07-22 at 11:25 -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
And user can execute only pre-determines queries/functions on system2.
If that were actually the case then the security issue wouldn't loom
quite so large, but the dynamic_query example in the plproxy
On 7/22/08, Marko Kreen [EMAIL PROTECTED] wrote:
On 7/22/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
Also, plroxy does
_nothing_ with passwords. That means the password for remote
connection must be in postgres user's .pgpass,
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed that. At minimum the documentation has to explain this
point
On 7/22/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed that. At minimum the
On 7/22/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 7/21/08, Tom Lane [EMAIL PROTECTED] wrote:
I looked through this a bit, and my principal reaction was what are
the security implications?
There are 2 aspects to it:
1. Function can be created only
Marko Kreen [EMAIL PROTECTED] writes:
And user can execute only pre-determines queries/functions on system2.
If that were actually the case then the security issue wouldn't loom
quite so large, but the dynamic_query example in the plproxy regression
tests provides a perfect example of how to
Marko Kreen [EMAIL PROTECTED] writes:
[ plproxy ]
I looked through this a bit, and my principal reaction was what are
the security implications? It seems like it'd be very easy to create
functions that allow untrusted users to execute arbitrary SQL on
other databases in the plproxy cluster. As
On 7/21/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
[ plproxy ]
I looked through this a bit, and my principal reaction was what are
the security implications? It seems like it'd be very easy to create
functions that allow untrusted users to execute
Marko Kreen [EMAIL PROTECTED] writes:
On 7/21/08, Tom Lane [EMAIL PROTECTED] wrote:
I looked through this a bit, and my principal reaction was what are
the security implications?
There are 2 aspects to it:
1. Function can be created only by superuser.
What I'm concerned about is who they
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
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
On 7/8/08, Simon Riggs [EMAIL PROTECTED] wrote:
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
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] 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.
On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
and potentially SPREAD BY as discussed in:
http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
That *sounds* cool, but its just the first part of the implementation of
a massively parallel executor. You'll quickly
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
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
On Tue, 2008-07-08 at 08:58 -0700, Joshua D. Drake wrote:
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
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
On 7/8/08, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
and potentially SPREAD BY as discussed in:
http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
That *sounds* cool, but its just the first part of the
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
On 7/8/08, Joshua D. Drake [EMAIL PROTECTED] wrote:
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
I took the libery and changed the status from WIP to Pending Review,
because the pending cleanups do not affect reviewing nor committing.
And anyway, because of the patch size I expect reviewers requesting
furthers changes so I'd like to push the tiny stuff to final version
of the patch.
--
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.
http://plproxy.projects.postgresql.org/faq/faq.html
The patch itself is attached, and also made available here:
21 matches
Mail list logo
