Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function
Date
Msg-id 13566.1332516714@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function
Next
From: Dimitri Fontaine
Date:
Subject: Re: Command Triggers patch v18