From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Dane Foster <studdugie(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Check constraints and function volatility categories |
Date: | 2016-02-01 21:23:41 |
Message-ID: | CAKFQuwarkqAXcAU68=iNtBfvLKjh=uZZ+U9+YHimVdeujdGotQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Feb 1, 2016 at 2:11 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 02/01/2016 12:52 PM, Dane Foster wrote:
>
>> On Mon, Feb 1, 2016 at 3:41 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
>> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>>
>>
>
>> As an example of where this leads see:
>>
>> http://www.postgresql.org/message-id/7224.1452275604@sss.pgh.pa.us
>>
>> Thanks for the heads up. The good news is all machine access to the
>> data will be via functions and views so I can inline the constraint in
>> the right places. In other news, this sucks! I have no idea what it
>>
>
> I could see moving your constraint into a per row trigger.
You'd need to basically replicate the current FK constraint setup but with
custom queries...you need the insert/update trigger on the main table and
then a insert/update/delete trigger on the referenced table to ensure that
actions just rejected if the relevant detail on the main table isn't
changed. Then decide whether you need something like "ON UPDATE/DELETE
CASCADE" instead of the default 'reject' behavior.
I take it you would need to ensure that these triggers are disabled during
dump/restore but am not certain on that point.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2016-02-01 21:48:12 | Re: Check constraints and function volatility categories |
Previous Message | Adrian Klaver | 2016-02-01 21:11:10 | Re: Check constraints and function volatility categories |