On June 14, 2017 7:53:05 PM PDT, Pavel Stehule <pavel.stehule@gmail.com> wrote: >2017-06-14 19:49 GMT+02:00 Andres Freund <andres@anarazel.de>: > >> On 2017-06-14 06:05:24 +0200, Pavel Stehule wrote: >> > 2017-06-14 5:53 GMT+02:00 Peter Eisentraut < >> peter.eisentraut@2ndquadrant.com >> > >: >> > >> > > On 6/13/17 17:08, Andres Freund wrote: >> > > > I wondered before if we shouldn't introduce "information only" >> > > > unenforced foreign key constraints for the catalogs. We kind >of >> > > > manually do that via oidjoins, it'd be nicer if we'd a function >> > > > rechecking fkeys, and the fkeys were in the catalog... >> > > >> > > I don't see why we couldn't just add a full complement of primary >and >> > > foreign key constraints (and unique constraints and perhaps some >check >> > > constraints). The argument is that they wouldn't normally do >anything, >> > > but they would help with documentation and browsing tools, and >they >> > > wouldn't hurt anything. >> >> Well, unique constraints are a bit more complicated because they rely >on >> an index, and we wouldn't e.g. maintain indexes with WHERE clauses or >> other expressions correctly. I'd be a bit wary of declaring such >> indexes as actually being fully valid, because we have planner logic >> that does planning based on various constraints now, it'd certainly >be >> annoying if some "re-check constraint" type queries would actually >have >> their joins optimized away or such... >> >> > These constraints can slowdown creating/dropping database objects - >> mainly >> > temp tables. >> >> How so? >> > >execution RI triggers
Those would obviously bit be fired, given Peter's description?
ok
Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.