Skip site navigation (1) Skip section navigation (2)

Feature requests after crash

From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Feature requests after crash
Date: 2002-02-21 21:24:55
Message-ID: 200202212124.g1LLOtFP005767@www1.translationforge (view raw or flat)
Thread:
Lists: 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

Next:From: Jean-Michel POUREDate: 2002-02-21 22:34:14
Subject: Re: [ODBC] Unicode support
Previous:From: Jean-Michel POUREDate: 2002-02-21 20:08:01
Subject: Re: Timestamp reverse engeneering bug

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group