To: "Merlin Moncure" <mmoncure@gmail.com>
cc: "Andrew Sullivan" <ajs@crankycanuck.ca>,
	"Pgsql Hackers" <pgsql-hackers@postgresql.org>
Subject: Re: function body actors (was: [PERFORM] viewing source code) 
In-reply-to: <b42b73150712210948g42498150h976c0b972d632faa@mail.gmail.com> 
References: <b42b73150712202109u26d05d01q4f1b8be8d29f763c@mail.gmail.com>
	<26811.1198215605@sss.pgh.pa.us>
	<20071221164826.GI10918@crankycanuck.ca>
	<b42b73150712210948g42498150h976c0b972d632faa@mail.gmail.com>
Comments: In-reply-to "Merlin Moncure" <mmoncure@gmail.com>
	message dated "Fri, 21 Dec 2007 12:48:51 -0500"
Date: Fri, 21 Dec 2007 13:57:44 -0500
Message-ID: <10257.1198263464@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Merlin Moncure" <mmoncure@gmail.com> 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?

Andrew's suggestion of an outside-the-database key server is
apropos, but I think it would end up being a situation where
the key server is under the control of whoever wrote the function
and wants to guard it against the end user.  The key server would
want some kind of authentication token but I think that could
perfectly well be an ID for the database server, not the individual
end user.  There's no need for anything as awkward as an interactive
sign-on, AFAICS.

			regards, tom lane