On Fri, Mar 23, 2012 at 11:31:54AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Why exactly was this thought to be a good idea:
> >>
> >>> * A NULL original expression disables use of transform functions while
> >>> * retaining all other behaviors.
>
> > I assumed that we were merely trying to avoid forcing the caller to
> > provide the expression tree if they didn't have it handy, and that the
> > comment was merely making allowance for the fact that someone might
> > want to do such a thing.
>
> How would they not have the original expression tree handy?
>
> But now that I'm looking at this ... the API specification for transform
> functions seems rather thoroughly broken anyway. Why are we passing the
> original expression and nothing else? This would appear to require the
> transform function to repeat all the input-normalization and
> simplification work done up to this point. It would seem to me to be
> more useful to pass the fully-processed argument list. I've not looked
> yet at the existing transform functions, but why would they want to know
> about the original node at all?
You suggested[1] passing an Expr instead of an argument list, and your reasons
still seem good to me. That said, perhaps we should send both the original
Expr and the simplified argument list. That will help if we ever want to
fully simplify x - y * 0. (Then again, the feature is undocumented and we
could change it when that day comes.)
[1] http://archives.postgresql.org/pgsql-hackers/2011-06/msg00915.php
The existing transform functions are trivial and could survive on nearly any
API we might consider. See varchar_transform().