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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Euler Taveira <euler(at)timbira(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: No, pg_size_pretty(numeric) was not such a hot idea
Date: 2012-06-04 23:01:37
Message-ID: 19618.1338850897@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <jim(at)nasby(dot)net> writes:
> On 5/27/12 2:54 PM, Euler Taveira wrote:
>> On 27-05-2012 10:45, Fujii Masao wrote:
>>> OK, let me propose another approach: add pg_size_pretty(int).

>> I wouldn't like to add another function but if it solves both problems... +1.

> FWIW, I would argue that the case of pg_size_pretty(8*1024*1024) is
> pretty contrived...

Yeah, possibly. In any case, I don't think we're making either of these
changes in 9.2, because the time for forcing initdbs is past. It would
only be realistic to think about changing pg_size_pretty() if we come
across some other, much more compelling reason to force a system catalog
contents change.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2012-06-05 00:48:03 Re: [RFC] Interface of Row Level Security
Previous Message Alexander Korotkov 2012-06-04 22:00:07 Re: Bug in new buffering GiST build code