On Sat, May 26, 2012 at 9:30 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
