Re: plpgsql_call_handler - Mailing list pgadmin-hackers

From Dave Page
Subject Re: plpgsql_call_handler
Date
Msg-id FED2B709E3270E4B903EB0175A49BCB10475C7@dogbert.vale-housing.co.uk
Whole thread Raw
In response to plpgsql_call_handler  (Jean-Michel POURE <jm.poure@freesurf.fr>)
List pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 20 February 2002 10:57
> To: Dave Page; pgadmin-hackers@postgresql.org
> 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.

pgadmin-hackers by date:

Previous
From: Jean-Michel POURE
Date:
Subject: plpgsql_call_handler
Next
From: Jean-Michel POURE
Date:
Subject: Re: plpgsql_call_handler