Re: More on inheritance and foreign keys

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, Albert Cervera Areny <albertca(at)hotpop(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: More on inheritance and foreign keys
Date: 2006-06-08 15:55:50
Message-ID: 44884886.5@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
>
>>>The solution to the foreign key problem seems easy if I
>>>modify PostgreSQL implementation and take off the ONLY word
>>>from the SELECT query, but it's not an option for me, as I'm
>
>
>>I think that the ONLY was wrong from day one :-(
>
>
> Well, sure, but until we have an implementation that actually *works*
> across multiple tables, it has to be there so that we can at least
> consistently support the current single-table semantics. Until we
> have some form of cross-table unique constraint (index or whatever)

I managed uniqueness using normal indexes and ins/upd triggers on all
child tables:

CREATE OR REPLACE FUNCTION checkchildsunique
RETURNS trigger AS
$BODY$BEGIN
IF EXISTS (
SELECT 1 FROM foo Master
WHERE Master.primaryKeyCol = NEW.primaryKeyCol)
THEN
RAISE EXCEPTION 'Primary Key violation in table % on %',
TG_RELNAME, TG_OP;
END IF;
RETURN NEW;
END;$BODY$ LANGUAGE 'plpgsql'

Shouldn't be too complicated to implement it as internal function.

Regards,
Andreas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-06-08 15:57:12 Re: ADD/DROP INHERITS
Previous Message Jim C. Nasby 2006-06-08 15:50:33 Type of bare text strings