On Wed, Jan 26, 2011 at 5:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers