"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? 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster