| От | Jim Nasby |
|---|---|
| Тема | Re: No, pg_size_pretty(numeric) was not such a hot idea |
| Дата | |
| Msg-id | 4FCD1C35.9060005@nasby.net обсуждение исходный текст |
| Ответ на | Re: No, pg_size_pretty(numeric) was not such a hot idea (Euler Taveira <euler@timbira.com>) |
| Ответы |
Re: No, pg_size_pretty(numeric) was not such a hot idea
|
| Список | pgsql-hackers |
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). >> If we do this, all usability and performance problems will be solved. >> > 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... when would you actually do somethinglike that? ISTM that any time you're using pg_size_pretty you'd be coming off a real datatype. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера