Has this been addressed?
---------------------------------------------------------------------------
Joe Conway wrote:
> 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;
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
