Feature requests after crash

Поиск
Список
Период
Сортировка
От Jean-Michel POURE
Тема Feature requests after crash
Дата
Msg-id 200202212124.g1LLOtFP005767@www1.translationforge
обсуждение исходный текст
Список pgadmin-hackers
Dear Dave,

When deleting pgadmin_* tables and functions, I dropped by error
plpgsql_call_handler which standed right after pgadmin in alphabetical
order... A GUI like pgAdmin2 is like a machine gun.

Bang Bang. I am shot down.

IMHO, dropping plpgsql_call_handler function is a total nonsense as :
- it breaks the language definition,
- it breaks all existing PLpgSQL functions,
- it cannot be recreated (or with different OID which is nonsense).

A language should only be dropped in the language tab. Waiting for your
approval to move it to system.

In the same field, we should prevent users from dropping functions used in:
- other functions,
- views,
- triggers.

Could we define read-only clauses in pgSchema objects to automatically query
->provides objects...
->requires objects...

Examples :
a) trigger foo -> requires -> function bar
b) function son -> requires -> father, mother (two functions)
c) function father -> provides -> son =  it cannot be dropped
d) table foo -> provides -> view bar = table cannot be dropped
e) Language plpgsql -> provides -> functions foo, bar, etc -> it cannot be
dropped

requires and provides are read-only functions returning a string. When
object->provides is null, the object can be dropped, otherwise it cannot. It
should be an option like row count.

It is not like a dependency chain but rather a security mechanism. Shall it
be added to the to-do-list? It does not seem too difficult to add. What do
you think my friend?

Cheers,
Jean-Michel

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Jean-Michel POURE
Дата:
Сообщение: Re: Timestamp reverse engeneering bug
Следующее
От: Jean-Michel POURE
Дата:
Сообщение: Re: [ODBC] Unicode support