You are right; I have forgotten to create a "trusted" language.
Mark
Tom Lane wrote:
>
> Mark Volpe <[EMAIL PROTECTED]> writes:
> > ERROR: Only users with Postgres superuser privilege are permitted to create a
> > function in the 'plpgsql' language
OK, I finally got around to adding the superuser check to my patch. So I try
to test it and...
ERROR: Only users with Postgres superuser privilege are permitted to create a
function in the 'plpgsql' language.
D'oh! So, if this is the case, then the last patch should be fine after all.
Mark
Pe
Good point. Would the issue be resolved by either:
- Only allowing the database superuser to use this mechanism?
- Allowing it only in trigger functions? (That way a user has to actually own
one of the tables)
Mark
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > > Peter might be refer
Avoid doing this with indexes on the table, though. I learned the hard way!
Mark
mlw wrote:
>
> Naomi Walker wrote:
> >
> > Does postgresql have any sort of fast bulk loader?
>
> It has a very cool SQL extension called COPY. Super fast.
>
> Command: COPY
> Description: Copies data between
I updated the patch to use the SET AUTHORIZATION { INVOKER | DEFINER }
terminology. Also, the function owner is now determined and saved at compile
time (no gotchas here, right?). It is located at
http://volpe.home.mindspring.com/pgsql/set_auth.patch
Mark
---(end of broa
Actually, I liked the SET AUTHORIZATION { DEFINER | INVOKER } terminology
mentioned earlier.
Mark
Zeugswetter Andreas SB wrote:
>
> > > This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
> > > commands in PL/pgSQL, which, respectively, change the effective uid to that
>
Sorry, I have decided not to follow the SQL standard ;-) PRIVILEGE is spelled
correctly in my patch.
This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
commands in PL/pgSQL, which, respectively, change the effective uid to that
of the function owner and back. It doesn't br
referential integrity code, and
thought this would be a nice (albeit incomplete) way to generalize this
ability.
Mark
Mark Volpe wrote:
>
> I know this topic was discussed a few months ago, but I'm wondering if any
> decisions have been reached on if, how, and when setuid functions
I know this topic was discussed a few months ago, but I'm wondering if any
decisions have been reached on if, how, and when setuid functions and triggers
might be implemented. If not, I have an idea to throw at it.
Thanks,
Mark
---(end of broadcast)---
