Greg Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org