Re: ALTER TYPE 3: add facility to identify further no-work cases
От | Tom Lane |
---|---|
Тема | Re: ALTER TYPE 3: add facility to identify further no-work cases |
Дата | |
Msg-id | 24348.1296072531@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TYPE 3: add facility to identify further no-work cases (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ALTER TYPE 3: add facility to identify further no-work cases
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane <tgl@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. >> 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. regards, tom lane
В списке pgsql-hackers по дате отправления: