Feature requests after crash - Mailing list pgadmin-hackers

From Jean-Michel POURE
Subject Feature requests after crash
Date
Msg-id 200202212124.g1LLOtFP005767@www1.translationforge
Whole thread Raw
List 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 by date:

Previous
From: Jean-Michel POURE
Date:
Subject: Re: Timestamp reverse engeneering bug
Next
From: Jean-Michel POURE
Date:
Subject: Re: [ODBC] Unicode support