* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: > >> I'm attaching a small patch to fix another comment typo in setrefs.c: > >> s/TIDs/OIDs/ > > > Fixed. > > I do not think "typo" is the right characterization. I'm too lazy to > check for sure, but I think what was accumulated was indeed TIDs at one > time. The proposed patch is not correct either: what we accumulate now is > syscache hash values. Might be best to just say "add PlanInvalItems for > user-defined functions", which is the wording used in some other places, > eg line 173.
Perhaps it was. I had looked at what was being called (which is record_plan_function_dependency) and noted that it was taking OIDs and certainly not TIDs. I agree that rewording it to refer to PlanInvalItems is better than just saying OIDs when we're actually looking up the OID and then adding a PlanInvalItem which includes PROCOID and the syscache hash value. Attached is a patch with the proposed change (against master, the back branches require slightly different patches due to nearby wording changes). Thanks! Stephen
From a562831ed53e73071243b4226c02ba1f0fbb93cb Mon Sep 17 00:00:00 2001 From: Stephen Frost <sfr...@snowman.net> Date: Thu, 10 Sep 2015 10:16:57 -0400 Subject: [PATCH] Use PlanInvalItems instead of OIDs As pointed out by Tom, we're not really adding OIDs (though that's what is passed to record_plan_function_dependency), we're adding a PlanInvalItem which contains PROCOID and the syscache hash value to invalItems. Rather than go into any of those details here, refer to what's added as PlanInvalItems, which will hopefully minimize any confusion. --- src/backend/optimizer/plan/setrefs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index 093d925..daeb584 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -1243,7 +1243,7 @@ copyVar(Var *var) * This is code that is common to all variants of expression-fixing. * We must look up operator opcode info for OpExpr and related nodes, * add OIDs from regclass Const nodes into root->glob->relationOids, and - * add catalog OIDs for user-defined functions into root->glob->invalItems. + * add PlanInvalItems for user-defined functions into root->glob->invalItems. * We also fill in column index lists for GROUPING() expressions. * * We assume it's okay to update opcode info in-place. So this could possibly -- 1.9.1
signature.asc
Description: Digital signature
