> -----Original Message----- > From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]] > Sent: 20 February 2002 10:57 > To: Dave Page; [EMAIL PROTECTED] > Subject: Re: [pgadmin-hackers] plpgsql_call_handler > > > Le Mercredi 20 F�vrier 2002 11:51, Dave Page a �crit : > > No, it's user defined because the user/sysadmin adds it himself. > > plpgsql_call_handler is a sys object added by user input. > > It does not necassary mean it is a user object.. Users may > think it is > allowed to drop this object ***because*** it is in user area. > There is a > potential breakage problem of databases using PLpgSQL. The only way we could handle plpgsql_call_handler is by specifically checking for it's name. What happens if a sysadmin renames it? What about the perl, tcl or python handlers, or untrusted versions of these? More importantly, what about handlers that people add themselves for languages we don't (yet) know about? All that aside, a system object (as pgSchema understands it) is an object that is part of the database (i.e. in template0), or an object that is implicitly created as a result of another action (i.e. a primary key index). Sequences created by serial columns are *not* system object as we have no way of telling how they were created. Therefore plpgsql_call_handler is not a system object. > > On the converse, this object should never be removed in > pgAdmin2 but withing > SQL queries. Why? Only the owner or a superuser could drop it anyway so there's no security risk. Regards, Dave.
Re: plpgsql_call_handler
Dave Page Wed, 20 Feb 2002 06:07:38 -0500 (EST)(envelope-from [email protected])
- Re: plpgsql_call_handler Dave Page
- Re: plpgsql_call_handler Jean-Michel POURE
- Dave Page
