[HACKERS] Re: [COMMITTERS] pgsql: Add notion of a transform function that can simplify function
On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas rh...@postgresql.org writes: Add notion of a transform function that can simplify function calls. Why exactly was this thought to be a good idea: * A NULL original expression disables use of transform functions while * retaining all other behaviors. AFAICT that buys nothing except to greatly complicate the API specification for simplify_function, something that is now proving problematic for Marti's requested refactoring [1]. If it's inappropriate for a transform function to modify a CoerceViaIO call, surely the transform function can be expected to know that. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Add notion of a transform function that can simplify function
On Fri, Mar 23, 2012 at 10:55:52AM -0400, Tom Lane wrote: Robert Haas rh...@postgresql.org writes: Add notion of a transform function that can simplify function calls. Why exactly was this thought to be a good idea: * A NULL original expression disables use of transform functions while * retaining all other behaviors. We last spoke of that idea here, albeit in minimal detail: http://archives.postgresql.org/pgsql-hackers/2011-06/msg00918.php AFAICT that buys nothing except to greatly complicate the API specification for simplify_function, something that is now proving problematic for Marti's requested refactoring [1]. If it's inappropriate for a transform function to modify a CoerceViaIO call, surely the transform function can be expected to know that. I did it that way because it looked wrong to pass the same CoerceViaIO node to transforms of both the input and output functions. Thinking about it again now, doing so imposes no fundamental problems. Feel welcome to change it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Add notion of a transform function that can simplify function
On Fri, Mar 23, 2012 at 11:31:54AM -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Mar 23, 2012 at 10:55 AM, Tom Lane t...@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(). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
