* 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


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
 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

Attachment: signature.asc
Description: Digital signature

Reply via email to