2017-06-15 5:02 GMT+02:00 Andres Freund <and...@anarazel.de>: > > > On June 14, 2017 7:53:05 PM PDT, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >2017-06-14 19:49 GMT+02:00 Andres Freund <and...@anarazel.de>: > > > >> On 2017-06-14 06:05:24 +0200, Pavel Stehule wrote: > >> > 2017-06-14 5:53 GMT+02:00 Peter Eisentraut < > >> peter.eisentr...@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. >