Jan Wieck wrote:
>
> Mark Hollomon wrote:
>
> > Yes, I've been thinking about that as well. It would be nice to have
> > permissions based on userid. Maybe the 'suid' stuff that is being
> > discussed in another thread will gives us a mechanism.
>
> I know, I know - and I know how. It cannot work for
> "internal" language functions. But for anything that goes
> through some loading (dynloader or PL call hander), the fmgr
> looks up pg_proc and put's informations into the FmgrInfo
> struct. Adding a setuid field to pg_proc and remembering that
> too wouldn't be too much and it then would know when calling
> such a beast. Fmgr then manages a current user stack which
> must be reset on a transaction abort. Anything that needs the
> current user simply looks at the toplevel stack entry.
That would work.
>
> This is totally transparent then for all non-builtin
> functions and all non-builtin triggers (where I don't know of
> one).
>
> Maybe I kept this far too long in mind. But I thought about
> some more complicated changes to the function call interface
> for a while that would require touching several dozens of
> source files (single argument NULL identification, returning
> tuples and tuple SET's). Doing SETUID would have been some
> DONE WHILE AT IT. I really should do it earlier than the
> SET's, because they require subselecting RTE's (which it the
> third thread now - eh - I better shut up).
I've been looking at returning a tuple. It looked to me that the
executor would handle a returned tuple okay, it was just SETs that
would cause problems. But I suspect I am wrong.
The best I could come up with for creating the tuple was using
heap_formtuple. But that requires a TupleDesc so I was going to
use heap_openr. But that needs the name of the relation which is
avaible from the Form_pg_data (?) structure for the return type,
which we already must get.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008
