Есть такой кусочек кода SELECT to_char(1,'09'), который судя по описанию к функции должен вернуть "01" а возвращает " 01" (с опережающим знаком пробел). Используется PGAdmin 1.8.4 и PostgreSQL 8.3. В чем прикол или где искать ошибку?
На странице документации http://postgresql.ru.net/manual/functions-formatting.html
есть куча примеров на эту тему.
Насколько я понял, пробел остаётся на месте знакового разряда. Т.е. если вы укажете не "1" , а "-1" то никаких пробелов у вас не будет. Функция используется для преобразования значений ДАТЫ И ВРЕМЕНИ, а не как просто строковая функция. Соответственно и преобразование осуществляется так, чтобы затем данные значения можно было засасывать как значения даты и времени обратно (я так понимаю).
Для преобразования числовых значений в строку вам нужны функции для работы со строками из другого раздела
как же тогда быть,
нужна строка где будет к, примеру ####YYYY##
где #- числа 1 до 9, а
YYYY - это результат to_char('0009', х), где х - это число от 0 до 9999.
сейчас выкручиваюсь так '####'||trim ( to_char('0009', х))||'##', - но как то не очень красиво.
В показанном вами примере вы (по моему скромному мнению) пытаетесь переложить на СУБД несвойственную ей работу - составление и комбинирование строк с форматированием. СУБД же предназначена для ВЫБОРКИ нужной информации из хранящейся в БД по определённым критериям. А всякие хитрые составления результатов, не имеющих прямое отношение к выборке (опять же по моему скромному мнению должны выполняться на клиенте).
Да СУБД предоставляет вам некий набор функций, но тем не менее, не стоит ожидать, что в этот набор войдёт всё то, что бы вам хотелось.
Это была лирика, уж простите мой брюзжание.
А в качестве решения попробуйте:
Гораздо приятнее получать готовый результат после выполения функции (запроса к базе), нежели после выполнения запроса еще составлять хитрые результаты. Извечные человеческие слабости.
Кроме того аналогичная по названию функция другой СУБД с похожим синтаксисом to_char(x,'009') возвращает немного другой результат.
Я могу прожить жизнь без необходимого, но без лишнего немогу. (с) Михаил Светлов
Приятней, не спорю. Но если речь идёт о производительности то лучше всё-таки собирать результаты на клиенте в ущерб приятности, но зато в пику производительности. Впрочем, я ответил на ваш исходный вопрос?
На странице
На странице документации
http://postgresql.ru.net/manual/functions-formatting.html
есть куча примеров на эту тему.
Насколько я понял, пробел остаётся на месте знакового разряда. Т.е. если вы укажете не "1" , а "-1" то никаких пробелов у вас не будет. Функция используется для преобразования значений ДАТЫ И ВРЕМЕНИ, а не как просто строковая функция. Соответственно и преобразование осуществляется так, чтобы затем данные значения можно было засасывать как значения даты и времени обратно (я так понимаю).
Для преобразования числовых значений в строку вам нужны функции для работы со строками из другого раздела
как же тогда быть, нужна
как же тогда быть,
нужна строка где будет к, примеру ####YYYY##
где #- числа 1 до 9, а
YYYY - это результат to_char('0009', х), где х - это число от 0 до 9999.
сейчас выкручиваюсь так
'####'||trim ( to_char('0009', х) )||'##', - но как то не очень красиво.В показанном вами примере вы
В показанном вами примере вы (по моему скромному мнению) пытаетесь переложить на СУБД несвойственную ей работу - составление и комбинирование строк с форматированием. СУБД же предназначена для ВЫБОРКИ нужной информации из хранящейся в БД по определённым критериям. А всякие хитрые составления результатов, не имеющих прямое отношение к выборке (опять же по моему скромному мнению должны выполняться на клиенте).
Да СУБД предоставляет вам некий набор функций, но тем не менее, не стоит ожидать, что в этот набор войдёт всё то, что бы вам хотелось.
Это была лирика, уж простите мой брюзжание.
А в качестве решения попробуйте:
где x то самое число от 0 до 9999
Гораздо приятнее получать
Гораздо приятнее получать готовый результат после выполения функции (запроса к базе), нежели после выполнения запроса еще составлять хитрые результаты. Извечные человеческие слабости.
Кроме того аналогичная по названию функция другой СУБД с похожим синтаксисом
to_char(x, '009')возвращает немного другой результат.Я могу прожить жизнь без необходимого, но без лишнего немогу. (с) Михаил Светлов
Приятней, не спорю. Но если
Приятней, не спорю. Но если речь идёт о производительности то лучше всё-таки собирать результаты на клиенте в ущерб приятности, но зато в пику производительности. Впрочем, я ответил на ваш исходный вопрос?