Re: ALTER TYPE 3: add facility to identify further no-work cases

On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ... A side issue is that I really
>> want to avoid adding a new parser keyword for this.  It doesn't bother
>> me too much to add keywords for really important and user-visible
>> features, but when we're adding stuff that's only going to be used by
>> 0.1% of our users it's really better if we can avoid it, because it
>> slows down the parser.  Maybe we could do something like:
>
>> CREATE CAST (source_type AS target_type)
>>     WITH FUNCTION function_name (argument_type, [, ...])
>>     [ ANALYZE USING function_name ]
>>     [ AS ASSIGNMENT | AS IMPLICIT ]
>
> I'm not terribly thrilled with the suggestion of "ANALYZE" here, because
> given the way we use that word elsewhere, people are likely to think it
> means something to do with statistics collection; or at least that it
> implies some deep and complicated analysis of the cast.
>
> I suggest using a phrase based on the idea that this function tells you
> whether you can skip the cast, or (if the sense is inverted) whether the
> cast has to be executed.  "SKIP IF function_name" would be nice but SKIP
> isn't an extant keyword either.  The best variant that I can come up
> with after a minute's contemplation of kwlist.h is "NO WORK IF
> function_name".  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

> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company