Re: Feature requests after crash

If you wish to add code to prevent dropping of functions that are *currently* in use as a language handler, then that's fine with me.

As for the dependencies, you will need to write parsers for at least the following languages to do what you propose:

SQL
pl/SQL
pl/pgSQL
pl/tcl
pl/perl
pl/sh
pl/python
pl/java (when it's written)

Without these parsers, we will not be able to track dependencies within functions or views.

Triggers should be easy enough though, but without views/functions (and tables/indexes/rules which can also depend on functions) there is little point.

I think the only practical answer is to wait for a pg_dependencies table in 7.3.

We could prevent dropping of languages that are in use though, as well as handlers.

Please finish the ALTER VIEW code before looking at this though - it's pretty much there now.

Good night,
Dave.

_____________Original message ____________
Subject: [pgadmin-hackers] Feature requests after crash
Sender: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
Date: Thu, 21 Feb 2002 22:22:56 +0000

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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)