Re: Identifying no-op length coercions - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Identifying no-op length coercions
Date
Msg-id 20110611211304.GB21098@tornado.leadboat.com
Whole thread Raw
In response to Re: Identifying no-op length coercions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Identifying no-op length coercions
List pgsql-hackers
On Sat, Jun 11, 2011 at 03:03:18PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > Good points.  I'm thinking, then, add an Expr argument to simplify_function()
> > and have the CoerceViaIO branch of eval_const_expressions_mutator() pass NULL
> > for both its simplify_function() calls.  If simplify_function() gets a NULL Expr
> > for a function that has a protransform, synthesize a FuncExpr based on its other
> > arguments before calling the transform function.  Seem reasonable?  Granted,
> > that would be dead code until someone applies a transform function to a type I/O
> > function, which could easily never happen.  Perhaps just ignore the transform
> > function when we started with a CoerceViaIO node?
>
> Until we actually have a use-case for simplifying I/O functions like this,
> I can't see going out of our way for it ...

Sounds good.  Updated patch attached, incorporating your ideas.  Before applying
it, run this command to update the uninvolved pg_proc.h DATA entries:
  perl -pi -e 's/PGUID(\s+\d+){4}/$& 0/' src/include/catalog/pg_proc.h

Thanks,
nm

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: procpid?
Next
From: Noah Misch
Date:
Subject: Re: deadlock_timeout at < PGC_SIGHUP?