Re: plpgsql_call_handler

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: plpgsql_call_handler
Дата
Msg-id FED2B709E3270E4B903EB0175A49BCB10475C7@dogbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на plpgsql_call_handler  (Jean-Michel POURE <jm.poure@freesurf.fr>)
Список 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 по дате отправления:

Предыдущее
От: Jean-Michel POURE
Дата:
Сообщение: plpgsql_call_handler
Следующее
От: Jean-Michel POURE
Дата:
Сообщение: Re: plpgsql_call_handler