From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Marc Munro <marc(at)bloodnok(dot)com>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using views for row-level access control is leaky |
Date: | 2009-10-23 16:02:24 |
Message-ID: | 1256313744.8450.1671.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> >> Sorry, what is happen if function is marked as "plan security"?
>
> > I was suggesting an intelligent default by which we could determine
> > function marking implicitly, if it was not explicitly stated on the
> > CREATE FUNCTION.
>
> The thought that's been in the back of my mind is that you could solve
> 99% of the performance problem if you trusted all builtin functions and
> nothing else. This avoids the question of who gets to mark functions
> as trustable.
That is a very good default. My experience is that those 1% of cases are
responsible for 99% of wasted time, so the ability to specify things for
user functions is critical. If we make user extensibility second rate we
will force solutions to be second rate also. (e.g. where would PostGIS
be without type-specific analyze functions?).
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-23 16:02:28 | Re: client_lc_messages |
Previous Message | Robert Haas | 2009-10-23 15:50:24 | Re: plpgsql EXECUTE will not set FOUND |