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
|
Список | 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 по дате отправления: