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

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

In response to

Responses

Browse pgsql-sql by date

  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