> On Tue, 23 Jan 2001, Forest Wilkinson wrote:
>
> > Jan,
> >
> > Thanks for the reply, but your solution is rather unattractive to me. It
> > requires that, any time a reference to an address id is changed, five
> > tables be searched for the address id. This will create unwanted overhead
If
On Wed, 24 Jan 2001 00:26:58 -0500 (EST), Michael Fork wrote:
>One other method is to setup up the foreign keys as ON DELETE RESTRICT,
>then outside of your transaction block issue a DELETE FROM address WHERE
>add_id = 1; If there are still records in the other tables referencing
>this record, i
One other method is to setup up the foreign keys as ON DELETE RESTRICT,
then outside of your transaction block issue a DELETE FROM address WHERE
add_id = 1; If there are still records in the other tables referencing
this record, it will error out and nothing will happen, however if no
related rec
Jan,
Thanks for the reply, but your solution is rather unattractive to me. It
requires that, any time a reference to an address id is changed, five
tables be searched for the address id. This will create unwanted overhead
every time a change is made. In order to make those searches even
remote
Jan Wieck wrote:
> Forest Wilkinson wrote:
> > I have a database in which five separate tables may (or may not) reference
> > any given row in a table of postal addresses. I am using the primary /
> > foreign key support in postgres 7 to represent these references.
> >
> > My problem is that, any
Forest Wilkinson wrote:
> I have a database in which five separate tables may (or may not) reference
> any given row in a table of postal addresses. I am using the primary /
> foreign key support in postgres 7 to represent these references.
>
> My problem is that, any time a reference is removed
