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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re[2]: lower() for varchar data by creating an index
Дата
Msg-id 23678.958664512@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re[2]: lower() for varchar data by creating an index  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re[2]: lower() for varchar data by creating an index
Следующее
От: "Mitch Vincent"
Дата:
Сообщение: LIKE and regex