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
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 |