Re: Re[2]: lower() for varchar data by creating an index - Mailing list pgsql-sql

From Christopher Sawtell
Subject Re: Re[2]: lower() for varchar data by creating an index
Date
Msg-id 00051910112500.13566@berty
Whole thread Raw
In response to Re: Re[2]: lower() for varchar data by creating an index  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-sql
On Fri, 19 May 2000, Bruce Momjian wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> You can get rid of it by deleting the pg_proc tuple directly.  I wonder
> > >> though whether RemoveFunction isn't being overly protective --- is there
> > >> any good reason not to allow people to delete built-in functions?
> > >> Obviously you have only yourself to blame if you delete integer equals
> > >> or something equally critical ;-) ... but there are a boatload of
> > >> built-ins that are by no means critical.  Comments anyone?
> > 
> > > I would throw a notice and keep going.  Should I commit the change?
> > 
> > What's the point of a notice?  "You just deleted OID equals.  Better
> > luck with your next database."  Either we think this is too dangerous to
> > be allowed even to the dbadmin, or we don't.
> > 
> > Actually, isn't there a backend switch that you have to set in order to
> > do *really* dangerous stuff (DML operations on the system classes, for
> > example)?  Maybe the right answer is to allow deletion of builtin
> > function entries only when that's set.
> > 
> > But on third thought, it's a little silly to guard the pg_proc entries
> > so carefully when we'll happily let the admin blow away the
> > corresponding pg_operator entries.  So I'd say just lose that error
> > check completely...
> 
> 
> But I think we should make sure they know they just deleted a built-in. 
> Seems like good feedback to a user who accidentally deletes one then
> can't figure out why his database is busted.  I can see that happening,
> and a NOTICE helps prevent really stupid bug reports.

Perhaps this might be a possible idea:
1) Only let the PostgreSQL `super-user' delete internal functions,
2) Let her delete the delete the non-essential functions with a default to yes
question before deleteion
3) Let her delete the nearly essential functions with a stronger worded message
and a default to no.
4) Do not allow deleteion of vital functions.

Somewhere in the doco please describe how to replace the functions from the
template or where-ever.

-- 
Sincerely etc.,
NAME       Christopher Sawtell - iOpen Technologies Ltd.CELL PHONE 021 257 4451ICQ UIN    45863470EMAIL      chris @
iopen. co . nz,  csawtell @ xtra . co . nzWWW        http://www.iopen.co.nzCNOTES
ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz
-->> Please refrain from using HTML or WORD attachments in e-mails to me <<--



pgsql-sql by date:

Previous
From: "Stephan Szabo"
Date:
Subject: Re: SQL command speed
Next
From: Tom Lane
Date:
Subject: Re: Foreign keys breaks tables permissions