On Fri, Sep 12, 2014 at 3:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Sep 11, 2014 at 7:14 AM, David Rowley <dgrowle...@gmail.com> > wrote: > >> 5. I've added a flag to pg_class called relhasfkey. Currently this gets > set > >> to true when a foreign key is added, though I've added nothing to set it > >> back to false again. I notice that relhasindex gets set back to false > during > >> vacuum, if vacuum happens to find there to not be any indexes on the > rel. I > >> didn't put my logic here as I wasn't too sure if scanning pg_constraint > >> during a vacuum seemed very correct, so I just left out the "setting it > to > >> false" logic based on the the fact that I noticed that relhaspkey gets > away > >> with quite lazy setting back to false logic (only when there's no > indexes of > >> any kind left on the relation at all). > > > The alternative to resetting the flag somehow is not having it in the > > first place. Would that be terribly expensive? > > I'd imagine not really expensive. I guess I just thought that it would be a good idea to save from having to bother looking in pg_constraint for foreign keys when none exist. The scan uses pg_constraint_conrelid_index so only would ever see the constraints for the rel being cached/loaded. > The behavior of relhaspkey is a legacy thing that we've tolerated only > because nothing whatsoever in the backend depends on it at all. I'm not > eager to add more equally-ill-defined pg_class columns. > > I guess it's certainly not required. It would be easier to add it later if we decided it was a good idea, rather than having to keep it forever and a day if it's next to useless. I'll remove it from the patch. Regards David Rowley
