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.