Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
Товарищи, не знаю даже, каким словом выразить свои чувства, но слово это явно нехорошее. Проблема такая: юзер вводит в форму некое число, которое затем вставляется в таблицу в поле типа numeric. Естественно, юзер может запросто вместо числа ввести абракадабру. И если он это делает, то при вставке запрос вылетает с ошибкой "invalid input syntax for integer". В MySQL, например, такие ситуации отлично разруливаются: число конвертится до тех пор, пока не встретится какой-либо неправильный символ, например строки "abc" и "abc123" конвертятся в 0, а строка "23abc" конвертится в 23. Есть ли подобная функциональносьть у Постгреса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2007, 02:51 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
uniqusТоварищи, не знаю даже, каким словом выразить свои чувства, но слово это явно нехорошее. Проблема такая: юзер вводит в форму некое число, которое затем вставляется в таблицу в поле типа numeric. Естественно, юзер может запросто вместо числа ввести абракадабру. И если он это делает, то при вставке запрос вылетает с ошибкой "invalid input syntax for integer". В MySQL, например, такие ситуации отлично разруливаются: число конвертится до тех пор, пока не встретится какой-либо неправильный символ, например строки "abc" и "abc123" конвертятся в 0, а строка "23abc" конвертится в 23. Есть ли подобная функциональносьть у Постгреса? Первое что приходит в голову создать правило (руль, RULE) для вставки в эту таблицу, и в нем уже конвертить то что нужно куда нужно. Это что бы добиться такой функциональности. Второе что приходит в голову - это кошмар и ужас ИМХО PG ведет себя более чем корректно себя ведет ругаясь матом на нерадивого юзера/программера. Ибо нефиг фсякую фигню вводить и юзеру нужно об этом говорить, внятно и конкретно - мол ты не прафф и иди ф газенваген цифры учить :) Тихая конвертация может приводить к последующим чудесам из серии - "Я ж вводил правильно, а оно мне...". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2007, 13:35 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
помню была какая то функция типа to_numeric. но я полностью поддерживаю, что это плохая идея в корне. данные надоо подавать в том виде, в каком они хранятся, а проверки надо делать до внесения в базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2007, 14:00 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
Я тоже полностью был согласен с этой концепцией, до тех пор пока не столкнулся с данной проблемой. А теперь получается, что поле должно быть numeric в любом случае, а то, что в него запишется - это уже полностью ответственность юзера, и если он ввёл туда случайно 123а, то он в результате должен получить там 123, а не ошибку SQL-запроса, а если ввел а123 - то должен получить ноль. to_numeric ведет себя вообще предельно странно: если было введено 123sdgdfh12, то все нечисленные символы тупо выкидываются, и в ячейку попадает значение 12312, что немного отличается от привычного мне подхода (MySQL бы записал только 123). А если юзер вообще ничего не ввел (пустая строка) - то опять же получаем ошибку SQL-запроса. Стандартная функция С atoi() ведет себя гораздо приличней в таких случаях. Видимо, придется таки разгребать эту ситуацию извне, что меня и удручает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2007, 02:18 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
если нет стандартных функций, то можно посмотреть в сторону регулярных выражений Verba volent, scripta manent ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2007, 10:26 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
uniqus... это уже полностью ответственность юзера, и если он ввёл туда случайно 123а, то он в результате должен получить там 123, а не ошибку SQL-запроса, а если ввел а123 - то должен получить ноль. а ваша ответственность, как программиста, проверить корректную информацию ввел пользователь или нет, а то, что пользователь может видеть sql ошибки, так это только ваши проблемы, а не субд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2007, 11:08 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
st_serg а ваша ответственность, как программиста, проверить корректную информацию ввел пользователь или нет, а то, что пользователь может видеть sql ошибки, так это только ваши проблемы, а не субд. Дык в том-то и дело, что в данном случае мне как программисту абсолютно побоку, что там ввёл себе пользователь, но требование заказчика таково, чтобы если он ввёл что-то левое, то оно по возможности сконвертилось бы в число, как в MySQL, а если не может сконвертиться в число - туда просто записался бы 0. А то, что юзер видит SQL-ошибку при неудачной конвертации - это тоже не совсем моя ответственность, это специфика движка CMS, на основе которого я всё это пишу, это его стандартное поведение. Я и без того уже намучался отлавливать ситуации с дубликатами в уникальных полях: в MySQL есть возможность выполнять запросы типа INSERT IGNORE, которые не генерируют ошибку, если нарушается уникальность индекса. В PostgreSQL такой фичи нет, и мне пришлось создавать специальные функции для вставки в нужные мне таблицы, которые отлавливают и игнорируют unique_violation эксепшены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2007, 20:36 |
|
||
|
Конвертация текста в numeric
|
|||
|---|---|---|---|
|
#18+
> чтобы если он ввёл что-то левое, то оно по возможности сконвертилось бы в число Телепатически? > как в MySQL Нет смысла воспроизводить баги MySQL в других СУБД. > то, что юзер видит SQL-ошибку при неудачной конвертации - это тоже не совсем моя ответственность А кто ошибки должен обрабатывать? Опять СУБД? И опять телепатически? > специфика движка CMS, на основе которого я всё это пишу, это его стандартное поведение Ну и кто виноват, что движок кривой? Снова PostgreSQL? > в MySQL есть возможность выполнять запросы типа INSERT IGNORE, которые не генерируют ошибку Да в MySQL вообще плюют на стандарты. И что, завидовать им? > мне пришлось создавать специальные функции для вставки в нужные мне таблицы Я никак не пойму, нафига тратить столько усилий, чтобы сделать что-то коряво? Может, лучше оставаться на MySQL и не пытаться использовать нормальные СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2007, 20:58 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34659549&tid=2005274]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 413ms |

| 0 / 0 |
