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

On Wed, Jan 26, 2011 at 5:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I don't mind confining the feature to casts to start with, but it might
>>> be a good idea to specify the check-function API in a way that would let
>>> it be plugged into a more generally available call-simplification hook
>>> later.
>
>> Got any suggestions?  My thought was that it should just get (type,
>> typemod, type, typemod) and return a boolean.  We could do something
>> more complicated, like Expr -> Expr, but I'm pretty unconvinced
>> there's any value there.
>
> Well, (type, typemod, type, typemod) would be fine as long as the only
> case you're interested in optimizing is typemod-lengthening coercions.
> I think we're going to want the more general Expr-to-Expr capability
> eventually.
>
> I guess we could do the restricted case for now, with the idea that
> there could be a standard Expr-to-Expr interface function created later
> and installed into the generic hook facility for functions that are cast
> functions.  That could look into pg_cast and make the more restricted
> call when appropriate.  (The meat of this function would be the same
> code you'd have to add to eval_const_expressions anyway for the
> hard-wired version...)

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

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