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@nortelnetworks.com

ESN 451-9008 (302)454-9008