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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: No, pg_size_pretty(numeric) was not such a hot idea
Дата
Msg-id CAHGQGwE5zZGgspsDwzW00kH9HRtgjRP_O-ce-_TsDOkohmgDoQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: No, pg_size_pretty(numeric) was not such a hot idea  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: No, pg_size_pretty(numeric) was not such a hot idea  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Tue, Jun 5, 2012 at 8:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <jim@nasby.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.

We cannot change a system catalog content at all. So, I'm worried
that we receive such complaints after the release of 9.2 but cannot
address that until 9.3.

Regards,

--
Fujii Masao


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: incorrect handling of the timeout in pg_receivexlog
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Backup docs