Re: Re[2]: lower() for varchar data by creating an index

> 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.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026