From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Where to stick function setuid |
Date: | 2000-09-09 17:43:59 |
Message-ID: | Pine.LNX.4.21.0009091611120.2484-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> > Btw., FunctionCallInvoke() would look to be the most prominent place to
> > hook in the "setuid" feature. For that purpose I'd make the macro an
> > inline function instead.
>
> Ugh. The performance cost would be excessive.
In the path of a "normal" function call is only one extra `if (bool)'
statement. There are certainly more "excessive" performance problems than
that, no?
> Instead, when fmgr is setting up to call a setuid function, have it
> insert an extra level of function handler that does the
> save/setup/restore of current UID.
I don't quite understand. Do you mean like a PL function handler? But then
this thing wouldn't work for external PL's unless we either have a setuid
version of each or have nested handlers.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Samplonius | 2000-09-09 20:25:22 | Re: Scalability, Clustering |
Previous Message | Alexey Raschepkin | 2000-09-09 16:03:30 | 'select pg_class from pg_class' error |