From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE 3: add facility to identify further no-work cases |
Date: | 2011-01-26 20:08:51 |
Message-ID: | 24348.1296072531@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-01-26 20:10:23 | Re: SSI patch version 14 |
Previous Message | Alex Hunsaker | 2011-01-26 20:08:03 | Re: arrays as pl/perl input arguments [PATCH] |