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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: gav <gav(at)nlr(dot)ru>, Mitch Vincent <mitch(at)venux(dot)net>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Re[2]: lower() for varchar data by creating an index
Date: 2000-05-18 15:41:52
Message-ID: 23678.958664512@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2000-05-18 15:44:26 Re: Re[2]: lower() for varchar data by creating an index
Previous Message Bruce Momjian 2000-05-18 15:28:37 Re: Re[2]: lower() for varchar data by creating an index