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. +