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

On Wed, Jan 26, 2011 at 5:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, if you're positive we're eventually going to want this in
>> pg_proc, we may as well add it now.  But I'm not too convinced it's
>> the right general API.  The number of people writing exactly x + 0 or
>> x * 0 in a query has got to be vanishingly small; I'm not eager to add
>> additional parse analysis time to every SQL statement that has a
>> function in it just to detect those cases.
>
> Actually, you've got that backwards: the facility I've got in mind would
> cost next to nothing when not used.  The place where we'd want to insert
> this in eval_const_expressions has already got its hands on the relevant
> pg_proc row, so checking for a nonzero hook-function reference would be
> a matter of a couple of instructions.  If we go with a pg_cast entry
> then we're going to have to add a pg_cast lookup for every cast, whether
> it turns out to be optimizable or not; which is going to cost quite a
> lot more.  The intermediate hook function I was sketching might be
> worthwhile from a performance standpoint even if we don't expose the
> more general feature to users, just because it would be possible to
> avoid useless pg_cast lookups (by not installing the hook except on
> pg_proc entries for which there's a relevant CAST WHEN function to call).

Oh, really? I was thinking the logic should go into find_coercion_pathway().

>> Even slightly more
>> complicated problems seem intractable - e.g. (x + 1) = x can be
>> simplified to constant false, and NOT ((x + 1) = x) can be simplified
>> to x IS NOT NULL, but under the proposed API those would have to hang
>> off of =(int4,int4), which seems pretty darn ugly.
>
> True, but where else are you going to hang them off of?  Not that I was
> particularly thinking of doing either one of those.

Beats me, just thinking out loud.

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