Wells Oliver-2 wrote > I have about 20 functions that all accept integer value inputs. > > I want to have views which call these functions using various SUMs of > integers e.g. > > select myfunction(sum(foo), sum(bar)) where foo and bar are integer types. > > This doesn't really work, you get: > > ERROR: function aggregates.stat_avg(bigint, bigint) does not exist > > Integer is definitely the right type to use for the underlying table. Do I > really need to have an explicit cast to bigint in these views? Seems > tedious. Define your aggregate functions to accept biginteger (either instead of or in addition to integer). The issue isn't that foo and bar are integers but that the sum of integers is a biginteger. In fact most of the core aggregate functions (like count(*)) output bigintegers since it minimizes the possibility of overflow. Unless you have a measured reason to optimize at integer you should just declare integer-like inputs as biginteger since all smaller sized types do automatically get upgraded as necessary - but obviously you cannot automatically downgrade. Also, you would technically have to cast the "bigint" to "integer" in order to get the view to work: SELECT myfunction(sum(foo)::integer, sum(bar)::integer); and just hope the sums are small enough. David J. Note that by habit I use integer much too often but I haven't actually explored the downsides to abolishing integer (except in tables, and maybe even then) and using biginteger everywhere. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Implicitly-casting-integer-to-bigint-9-1-tp5765831p5765833.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
