From: | "Mark Hollomon" <mhh(at)nortelnetworks(dot)com> |
---|---|
To: | Jan Wieck <jwieck(at)debis(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | fmgr interface [was: plperl inital pass] |
Date: | 1999-07-27 13:01:01 |
Message-ID: | 379DAD8D.6B1DBA10@americasm01.nt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Todd Vierling | 1999-07-27 13:04:58 | Re: More on shared objects problem |
Previous Message | Mark Hollomon | 1999-07-27 12:54:47 | dynloader and PLs [was: plperl intial pass] |