Date: Mon, 24 Jul 2006 16:22:36 -0500
From: Bruno Wolff III <bruno@wolff.to>
To: Richard Jones <rich@annexia.org>
Cc: pgsql-sql@postgresql.org
Subject: Re: Referential integrity (foreign keys) across multiple tables
Message-ID: <20060724212236.GA14923@wolff.to>
Mail-Followup-To: Bruno Wolff III <bruno@wolff.to>,
	Richard Jones <rich@annexia.org>, pgsql-sql@postgresql.org
References: <20060722133257.GA9785@furbychan.cocan.org>
	<20060723183237.GA22586@wolff.to>
	<20060724085907.GA19981@furbychan.cocan.org>
	<20060724175148.GA25994@wolff.to>
	<20060724175320.GA18434@furbychan.cocan.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060724175320.GA18434@furbychan.cocan.org>
User-Agent: Mutt/1.4.2.1i

On Mon, Jul 24, 2006 at 18:53:20 +0100,
  Richard Jones <rich@annexia.org> wrote:
> 
> I'm not sure what this means.  By "data integrity" I just meant that I
> don't want applications to create page_contents.link_name fields which
> could point to non-existent URLs.  (A URL consists of a particular
> hostid and url, since you're not allowed to have one host pointing to
> pages on another, and this is where the requirement for a foreign key
> which spans two tables comes from).  Perhaps I meant "data
> consistency"?  Anyway without some sort of check, be it a reference or
> a trigger -- assuming a trigger is possible -- then an application
> might create such a bad link.

I think part of the problem might have been over simplification of the
problem. In your example there was no reason to create that new column since
the information was available by doing a join between two tables and this
would prevent a problem with data being out of sync.

I see from another message in this thread that there is really more to
this example. It may be that you still don't need the new column, but I
haven't examined the new example carefully to say one way or the other.