| From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | Bill Studenmund <wrstuden(at)zembu(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alex Pilosov <alex(at)pilosoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_depend |
| Date: | 2001-07-20 00:13:36 |
| Message-ID: | 20010719191336.A32693@rice.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 20, 2001 at 08:45:05AM +0900, Hiroshi Inoue wrote:
>
> It doesn't seem preferable that the default(unadorned) DROP
> allows reattachement after the DROP. The default(unadorned) DROP
> should be the same as DROP RESTRICT(or CASCADE because the current
> behabior is halfway CASCADE?). How about adding another keyword
> to allow reattachment after the DROP ?
> All depende(a?)nt objects must be re-complied after the
> reattachment and the re-compilation would fail if the new table
> isn't sufficiently like the old one.
>
> Anyway my opinion seems in a minority as usual.
>
How about making that functionality happen with ALTER <FOO> REPLACE
as Tom suggested? If I'm wanting to change an underlying table, how
likely is it that I don't have the replacement ready right now?
So, instead of:
DROP <FOO> <name> WITH INTENT TO REPLACE
CREATE <FOO> <name> <body>
it's just:
ALTER <FOO> <name> REPLACE <body>
All nice and transactional: if the attempt to reattach one of the
subordinate objects fails, you roll back to the old one.
Ross
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2001-07-20 00:24:09 | Re: OID wraparound (was Re: pg_depend) |
| Previous Message | Bill Studenmund | 2001-07-20 00:07:31 | Re: pg_depend |