fmgr interface [was: plperl inital pass]

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(at)nortelnetworks(dot)com

ESN 451-9008 (302)454-9008