Re: Bug in RENAME TO?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in RENAME TO?
Date: 2004-06-12 18:02:29
Message-ID: 26739.1087063349@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I said:
> It's likely that there are some pg_proc entries that you can break the
> system beyond repair by renaming, but I'd expect they are a relatively
> small minority (the system's hardwired references are by OID not name).

Just for fun I tried

d=# update pg_proc set proname = 'z' || proname;
UPDATE 1727

The database got a bit unpleasant to use, mainly because most of
psql's \d commands broke:

d=# \d foo
ERROR: function pg_catalog.pg_table_is_visible(oid) does not exist

but standard SQL operations still worked, and in fact I was able to
undo the damage with

d=# update pg_proc set proname = zsubstring(proname,2);
UPDATE 1727

So I say there isn't any reason to prohibit renaming functions just
because they were created at initdb time. The worst-case scenario
is you have to rename 'em back. Likewise for ALTER OWNER.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Carl E. McMillin 2004-06-12 18:24:44 Re: I just got it: PostgreSQL Application Server -- a new project.
Previous Message Stephan Szabo 2004-06-12 17:55:50 Re: Nested xacts: looking for testers and review