Re: Implicitly casting integer to bigint (9.1)

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.