2016-11-21 21:16 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Something I just noticed is that transformTableExpr takes a TableExpr > > node and returns another TableExpr node. That's unlike what we do in > > other places, where the node returned is of a different type than the > > input node. I'm not real clear what happens if you try to re-transform > > a node that was already transformed, but it seems worth thinking about. > > We're not 100% consistent on that --- there are cases such as RowExpr > and CaseExpr where the same struct type is used for pre-parse-analysis > and post-parse-analysis nodes. I think it's okay as long as the > information content isn't markedly different, ie the transformation > just consists of transforming all the sub-nodes. > > Being able to behave sanely on a re-transformation used to be an > issue, but we no longer expect transformExpr to support that. >
I was not sure in this case - using new node was more clear for me - safeguard against some uninitialized or untransformed value. There in only few bytes memory more overhead. regards Pavel > > regards, tom lane >