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

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026