Greg Stark <gsstark@mit.edu> writes:
> So I'm thinking it's better to leave my implementation as is rather than
> reimplement it using the relcache. Or would it be better to use the relcache
> and then when and if it comes to making inherited tables inherit foreign key
> constraints look into adding foreign keys and the deferrable and isdeffered
> flags to the relcache?
Well, it's reasonable to assume that the relcache entries for check
constraints include everything that's semantically meaningful, because
that's what the actual constraint enforcement code looks at. IE, if
we ever did have deferrable check constraints then that flag would get
added to the entries.
However, we don't keep any info about FK constraints in the relcache
(except indirectly via their triggers). At the moment I can't think
of any reason why we should.
If you're happy with the code looking directly at pg_constraint then
I see no reason to change it. I just mentioned the relcache because
I thought you were concerned about the performance of a pg_constraint
search.
regards, tom lane
