Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm not entirely following here. If the function is coded in C, > then it can pretty much do what it pleases independently of what > user ID is thought to be executing it at the SQL level. That > would really only matter if you were doing some SQL stuff via the > SPI interface Yeah, there is a lot of SPI through cached prepared statements. > if that's the case, couldn't the C function set the appropriate > role to use for itself, anyway? I suppose it could, though I never really thought about that aspect of the issue before. > (In other words, it's not that hard to build a "RUN AS other-user" > feature into a C function, even without any support from the rest > of the system.) Similar to what Stephen says in his post that came through while I was typing this, I would be less comfortable with this being a hand-rolled feature of individual C functions than having some more systematic way to handle it. Even if there is the possibility that someone could subvert the more systematic way of doing things with clever C code, I think the systematic approach reduces risk from error and would tend to make hostile code in C functions stand out more. And having the information at the catalog level would make the intended usages easier to manage. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
