Re: No, pg_size_pretty(numeric) was not such a hot idea

On Sat, May 26, 2012 at 9:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In 9.1:
>
> regression=# select pg_size_pretty(8*1024*1024);
>  pg_size_pretty
> ----------------
>  8192 kB
> (1 row)
>
> In HEAD:
>
> regression=# select pg_size_pretty(8*1024*1024);
> ERROR:  function pg_size_pretty(integer) is not unique
> LINE 1: select pg_size_pretty(8*1024*1024);
>               ^
> HINT:  Could not choose a best candidate function. You might need to add explicit type casts.
>
> The argument for adding pg_size_pretty(numeric) was pretty darn thin in
> the first place, IMHO; it does not seem to me that it justified this
> loss of usability.

Ouch! But removing pg_size_pretty(numeric) causes another usability
issue, e.g., pg_size_pretty(pg_xlog_location_diff(...)) fails. So how about
removing pg_size_pretty(bigint) to resolve those two issues?
I guess pg_size_pretty(numeric) is a bit slower than bigint version, but
I don't think that such a bit slowdown of pg_size_pretty() becomes
a matter practically. No?

Regards,

--
Fujii Masao