Robert Haas <robertmh...@gmail.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). > 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers