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?
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
