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 по дате отправления: