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

From Tom Lane
Subject Re: Re[2]: lower() for varchar data by creating an index
Date
Msg-id 23678.958664512@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re[2]: lower() for varchar data by creating an index  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Re[2]: lower() for varchar data by creating an index  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re[2]: lower() for varchar data by creating an index  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-sql
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...
        regards, tom lane


pgsql-sql by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re[2]: lower() for varchar data by creating an index
Next
From: "Mitch Vincent"
Date:
Subject: LIKE and regex