Re: Re[2]: lower() for varchar data by creating an index
От | Christopher Sawtell |
---|---|
Тема | Re: Re[2]: lower() for varchar data by creating an index |
Дата | |
Msg-id | 00051910112500.13566@berty обсуждение исходный текст |
Ответ на | Re: Re[2]: lower() for varchar data by creating an index (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-sql |
On Fri, 19 May 2000, Bruce Momjian wrote: > > 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. Perhaps this might be a possible idea: 1) Only let the PostgreSQL `super-user' delete internal functions, 2) Let her delete the delete the non-essential functions with a default to yes question before deleteion 3) Let her delete the nearly essential functions with a stronger worded message and a default to no. 4) Do not allow deleteion of vital functions. Somewhere in the doco please describe how to replace the functions from the template or where-ever. -- Sincerely etc., NAME Christopher Sawtell - iOpen Technologies Ltd.CELL PHONE 021 257 4451ICQ UIN 45863470EMAIL chris @ iopen. co . nz, csawtell @ xtra . co . nzWWW http://www.iopen.co.nzCNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz -->> Please refrain from using HTML or WORD attachments in e-mails to me <<--
В списке pgsql-sql по дате отправления: