From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Help with restoring a dump in Tar format? (dependencies/ordering) |
Date: | 2017-06-06 00:52:02 |
Message-ID: | 9f85219d-4efb-e2ac-40fb-dc7888dcf9fa@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 6/5/2017 5:49 PM, David G. Johnston wrote:
> On Mon, Jun 5, 2017 at 5:40 PM, John R Pierce <pierce(at)hogranch(dot)com
> <mailto:pierce(at)hogranch(dot)com>>wrote:
>
> āiā
> ndeed, any sort of constraint that invokes a function call which
> looks at other tables could later be invalidated if those other
> tables change, and postgres would be none the smarter. the same
> goes for trigger based checks.
>
>
> ā Yes. I could imagine a new kind of "multi-referential trigger" that
> would specify all relations it touches and the function to fire when
> each of them is updated. While you'd still have to write the
> functions correctly it would at least allow one to explicitly model
> the multi-table dynamic in pg_catalog. Lacking that CHECK is no worse
> than TRIGGER and we've decided to say "use triggers".
at $job, the policy is, AVOID ALL TRIGGERS AND FANCY CONSTRAINTS :)
they don't even like using foreign key references, and rely on code
logic to do most joins in the performance-critical OLTP side of things.
--
john r pierce, recycling bits in santa cruz
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2017-06-06 00:52:13 | Re: Help with restoring a dump in Tar format? (dependencies/ordering) |
Previous Message | David G. Johnston | 2017-06-06 00:49:11 | Re: Help with restoring a dump in Tar format? (dependencies/ordering) |