On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis <pg...@j-davis.com> wrote: > I think the best we'll do is be able to hack on some of the things that > we actively want and have clear use cases for, such as type interfaces. > We might have to give up on some of the more ambitious ideas that > involve propagating interesting information through the type inference > system; or having any real type that wasn't declared with CREATE TYPE. > Consider that right now we bundle the element type information along > with the array _value_.
Here are some weaknesses in the SUM aggregate that run up against the type system. Maybe they'll help crystallize some discussion: SUM(int2) => int4 SUM(int4) => int8 SUM(int8) => numeric Some weaknesses: SUM, of any precision, assumes that the precision being accumulated into (which is also the return-precision) is enough to avoid overflow. This is generally the case, but there's no reason why it *must* be true. I'm especially looking at the int2 to int4 conversion. One could imagine a more interesting scenario where overflow behavior could occur much more easily. SUM always promotes types upwards in precision, and is unable to keep types of the smallest possible precision should SUM expressions be composed. SUM is unable to maintain any supplementary information about precision, i.e. say anything interesting about the typmod, which defeats or makes impossible many interesting optimizations. I think that a type-interface system moves towards solving the first couple of problems, since SUM can return some abstract type such as "Integer" and use that to promote more aggressively (avoiding overflow) or keep representations small (avoiding unnecessary promotion) at run-time. It might require Integer to be an abstract, non-storable data type, though, so the current CREATE TYPE is not going to make life easy. The third problem is slightly different...it might require some user-pluggable code to be called as part of semantic analysis. I have felt the idea of making a Postgres Type a more robust first-class data type and somehow being able to attach a function to another function/aggregate that is responsible for getting called during semantic analysis and returning the proper signature roll around in my head, but it might be the whispers of cthulu, too. fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
