From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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-19 17:39:38 |
Message-ID: | Pine.LNX.4.21.0005191337270.489-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane writes:
> 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.
I'd have to agree.
> 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.
You might be referring to pg_shadow.usecatupd, but that only covers direct
catalog updates. The postgres -O switch allows system schema changes, that
doesn't apply either.
Anyway, shouldn't you be able to do CREATE FUNCTION xxx (...) LANGUAGE
'internal'; to recreate it? (And that wouldn't actually require things
like oideq to be in pg_proc, would it?)
--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-19 17:44:15 | Re: Foreign keys breaks tables permissions |
Previous Message | Peter Eisentraut | 2000-05-19 17:39:14 | Re: Foreign keys breaks tables permissions |