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?
- Andres
