| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Happy column dropping |
| Date: | 2000-01-24 23:48:47 |
| Message-ID: | Pine.LNX.4.21.0001242215060.525-100000@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2000-01-22, Tom Lane mentioned:
> > 2) how do I find out if the dropped column is referenced in a constraint,
> > trigger, rule (this is necessary for a correct RESTRICT/CASCADE
> > implementation)
>
> Actually it's worse than that: you need to be prepared to renumber the
> columns after the dropped one, too. Probably what you will need to do
> is read in and deparse all the relevant rules and triggers, then reparse
> them against the updated table schema. Ugly. And no, I have no idea
> how you even *find* all the relevant rules. (Jan?)
Perhaps their should be a pg_attribute.attisusedbytrigger::oid,
pg_attribute.attisconstrainedbyconstr::oid, etc. Eventually, I think, this
is unavoidable if you want DROP TABLE to do the right thing as well, and
scanning and decoding possibly hundreds of rules, triggers, and
constraints won't get you far.
--
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 | Peter Eisentraut | 2000-01-24 23:48:59 | Re: [HACKERS] Happy column dropping |
| Previous Message | Peter Eisentraut | 2000-01-24 23:48:33 | Re: [HACKERS] psql updates |