Daniel Farina <drfarina@acm.org> writes:
> There are other ways one might be able to attack the performance part
> of the problem, but consider the loss of information about the type
> from int(2|4|8) to numeric when composing a series of sums: we know
> the value produced fits the abstract notion of an Integer, but we lose
> that information. The same could be said of SUM(x::numeric(1000,0))
> yielding an unrestricted numeric, rather than one of scale 0. Not only
> is there more information available to the user, but the optimizer
> should be able to benefit from that information as well. However, for
> an arbitrary user-defined operator to take advantage it would seem to
> me that there needs to be a hook where some reasoning can take place
> over its input types and subsequently determine the return prototype
> at that call site.
Yeah, this has been discussed before. The problem is that it's too much
work for too little reward. There are too many different possible
behaviors for functions, and nobody is going to go through and write
a subtype-inference helper function for every function in the system,
or even any usefully large fraction of the functions in the system.
What's more, the subtype definitions have largely been predetermined
for us by SQL, and predetermined in such a way that knowing the subtype
isn't really all that exciting. Is anybody willing to put in
months of work to teach the system that sum(numeric(7,0)) yields
numeric(something,0) rather than numeric(something,something)?
I doubt it. The return on that knowledge would be too small, and
there are too many cases where you couldn't deduce anything anyway.
regards, tom lane