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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2013-01-25T21:16:52Z
Lists: pgsql-hackers
On Wed, Oct 10, 2012 at 11:49:50AM -0700, Josh Berkus wrote:
> 
> >> Assuming that's how 9.2 ships, we might as well wait to see if there
> >> are any real complaints from the field before we decide whether any
> >> changing is needed.
> 
> So, here's a complaint: 9.2 is breaking our code for checking table sizes:
> 
> postgres=# select pg_size_pretty(100);
> ERROR:  function pg_size_pretty(integer) is not unique at character 8
> HINT:  Could not choose a best candidate function. You might need to add
> explicit type casts.
> STATEMENT:  select pg_size_pretty(100);
> ERROR:  function pg_size_pretty(integer) is not unique
> LINE 1: select pg_size_pretty(100);
>                ^
> HINT:  Could not choose a best candidate function. You might need to add
> explicit type casts.
> 
> Obviously, we can work around it though.  Let's see if anyone else
> complains ...

Where are we on this?  I still see this behavior:

	test=> SELECT pg_size_pretty(100);
	ERROR:  function pg_size_pretty(integer) is not unique
	LINE 1: SELECT pg_size_pretty(100);
	               ^
	HINT:  Could not choose a best candidate function. You might need to add explicit type casts.

\df shows:

	test=> \df pg_size_pretty
	                               List of functions
	   Schema   |      Name      | Result data type | Argument data types |  Type
	------------+----------------+------------------+---------------------+--------
	 pg_catalog | pg_size_pretty | text             | bigint              | normal
	 pg_catalog | pg_size_pretty | text             | numeric             | normal
	(2 rows)

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +