Re: v10beta pg_catalog diagrams

2017-06-15 5:02 GMT+02:00 Andres Freund <andres(at)anarazel(dot)de>:

>
>
> On June 14, 2017 7:53:05 PM PDT, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >2017-06-14 19:49 GMT+02:00 Andres Freund <andres(at)anarazel(dot)de>:
> >
> >> On 2017-06-14 06:05:24 +0200, Pavel Stehule wrote:
> >> > 2017-06-14 5:53 GMT+02:00 Peter Eisentraut <
> >> peter(dot)eisentraut(at)2ndquadrant(dot)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.
>