Re: VALUES clause memory optimization

Tom Lane wrote:
> The reason we could safely list_free inside transformInsertRow is that
> we know all its callers have just built the passed-in list and so there
> are no other pointers to it.  That doesn't apply in the general case of
> grammar output.

What about for the specific case of an InsertStmt? It seems that we 
could at least get away with freeing the raw-expression list in that case.

In terms of freeing an entire arbitrary node, could we create a 
backend/nodes/freefuncs.c file that does a recursive freeObject() 
similar to the way copyObject() does in backend/nodes/copyfuncs.c?

> My advice is to get that low-hanging fruit
> in transformInsertRow and leave the other ideas for 8.3.

OK. This should be safe also, correct?

Thanks,

Joe

8<----------------------------------------
diff -c -r1.341 analyze.c
*** src/backend/parser/analyze.c    2 Aug 2006 01:59:46 -0000    1.341
--- src/backend/parser/analyze.c    2 Aug 2006 05:13:20 -0000
***************
*** 2191,2196 ****
--- 2196,2202 ----      for (i = 0; i < sublist_length; i++)      {          coltypes[i] =
select_common_type(coltype_lists[i],"VALUES");
 
+         list_free(coltype_lists[i]);      }
      newExprsLists = NIL;