From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Axel Rau <Axel(dot)Rau(at)Chaos1(dot)DE> |
Cc: | daryl(at)brandywine(dot)com, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Updating cidr column with network operator |
Date: | 2005-09-23 17:32:04 |
Message-ID: | 20050923173204.GA80995@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, Sep 23, 2005 at 06:31:17PM +0200, Axel Rau wrote:
> Networks change during time, being diveded or aggregated or you just
> enter wrong data during insert.
Have you considered using a CHECK constraint and/or a trigger to
ensure that the network in the network column contains the address
in the id column? If you have and rejected the idea, what were the
reasons?
> With the UPDATE below, I want to correct the addresses to again point
> at the right net.
Does the following statement do what you want? It shouldn't touch
the records with no matching network -- what do you want to happen
in those cases? This update also might not give the results you
want if more than one network matches.
UPDATE address SET network = n.id FROM network n WHERE address.id << n.id;
> While writing this, I learn that because of the pk in network,
> UPDATEs will be difficult to accomplish (you may need a temporary
> net to park all addresses of a network to be divided, make the
> change in network and use the UPDATE below to adjust A.network. I
> use net '0.0.0.0/32' as 'UNKNOWN' net or for parking.
I'm not sure I understand what you're saying, but if you're concerned
about foreign key violations then making the foreign key constraints
deferrable and deferring them during certain updates might remove
the need for a temporary "parking" network.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | Daryl Richter | 2005-09-23 18:43:50 | Re: Updating cidr column with network operator |
Previous Message | Matthew Peter | 2005-09-23 17:02:44 | Re: delete item[5] from varchar[] array??? |