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...)
> I'd like to see some kind of appropriate
> hook for interjecting selectivity estimates for cases that we
> currently can't recognize, but my gut feeling is that that's
> insufficiently related at the problem at hand to worry about it.
Agreed, that seems a bit off-topic. There are ancient comments in the
source code complaining about the lack of selectivity hooks for function
(as opposed to operator) calls, but that's not what Noah signed up to
fix. In any case I'm not sure that expression simplification is
closely connected to selectivity estimation --- to my mind it's an
independent process that is good to run first. As an example, the ALTER
TABLE case has a use for the former but not the latter.
regards, tom lane
