On Wed, Jan 26, 2011 at 05:32:00PM -0500, Tom Lane wrote: > 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).
If we hook this into eval_const_expressions, it definitely seems cleaner to attach the auxiliary function to the pg_proc. Otherwise, we'd reconstruct which cast led to each function call -- is there even enough information available to do so unambiguously? Unlike something typmod-specific, these functions would effectively need to be written in C. Seems like a perfectly acceptable constraint, though. For the syntax, then, would a new common_func_opt_item of "WHEN func" fit? That covers fully-removable casts, but ALTER TABLE still needs to identify casts that may throw errors but never change the value's binary representation. Where does that fit? Another pg_proc column for a function called to answer that question, called only from an ALTER TABLE-specific code path? Thanks for the feedback/analysis. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
