On Fri, Dec 21, 2007 at 01:57:44PM -0500, Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > ISTM the main issue is how exactly the authenticated user interacts
> > with the actor to give it the information it needs to get the real
> > key. This is significant because we don't want to be boxed into an
> > actor implementation that doesn't allow that interaction.
>
> We don't? What purpose would such a setup serve? I would think
> that for the applications we have in mind, the *last* thing you
> want is for the end user to hold the key. The whole point of this
> is to keep him from seeing the function source code, remember?
Hmm; this may be exactly part of the problem, though. It seems there are
two possible cases in play:
1. Protect the content in the database (in this case, function bodies)
from _all_ users on a given server. This is a case where you want to
protect (say) your function body from your users, because you have a
closed-source application.
2. Protect the content of a field from _some_ users on a given system,
based on the permissions they hold. This is roughly analagous to others not
being able to look in the table I created, because I haven't GRANTed them
permission.
(2) is really a case for column-level access controls, I guess. But if
we're trying to solve this problem too, then user passwords or something
make sense.
A
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
