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
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 |