On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> If you didn't mind inverting the sense of the result >>> then we could use "EXECUTE IF function_name". > >> What about borrowing from the trigger syntax? > >> WITH FUNCTION function_name (argument_type, [...]) WHEN >> function_that_returns_true_when_the_call_is_needed > > That's a good thought. Or we could use WHEN NOT check_function if you > want to keep to the negative-result semantics.
Seems a bit contorted; I don't see any particular reason to prefer positive vs negative semantics in this case. >>> One point worth making here is that eval_const_expressions() does not >>> currently care very much whether a function call came from cast syntax >>> or explicitly. It might be worth thinking about whether we want to have >>> a generic this-function-call-is-a-no-op simplifier hook available for >>> *all* functions not just those that are casts. I'm not sure we want to >>> pay the overhead of another pg_proc column, but it's something to think >>> about. > >> It's not obvious to me that it has a use case outside of casts, but >> it's certainly possible I'm missing something. > > A possible example is simplifying X + 0 to X, or X * 0 to 0. I've never > wanted to inject such datatype-specific knowledge directly into the > planner, but if we viewed it as function-specific knowledge supplied by > a per-function helper routine, maybe it would fly. Knowing that a cast > function does nothing useful for particular cases could be seen as a > special case of this type of simplification. Oh, I see. The times I've seen an issue with those kinds of expressions have always been related to selectivity estimation. For example, you'd like to get a selectivity estimate of 1-nullfrac for (x+0)=x and 0 for (x+1)=x, and maybe (1-nullfrac)/2 for (x%2)=0. This would only handle the first of those cases, so I'm inclined to think it's too weak to have much general utility. The casting cases can, I think, have a much larger impact - they occur more often in practice, and if you can (e.g.) avoid an entire table rewrite, that's a pretty big deal. Another semi-related problem case I've run across is that CASE WHEN ... THEN 1 WHEN ... THEN 2 END ought to be known to only ever emit 1 and 2, and the selectivity of comparing that to some other value ought to be computed on that basis. But now I'm really wandering off into the weeds. -- 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