Литье колонн Postgres - PullRequest
       9

Литье колонн Postgres

2 голосов
/ 18 мая 2010

У меня есть запрос

SELECT assetid, type_code, version, name, short_name, status, languages,
charset, force_secure, created, created_userid, updated, updated_userid,
published, published_userid, status_changed, status_changed_userid
FROM sq_ast WHERE assetid = 7

который не работает и выбрасывает

ERROR: operator does not exist: character varying = integer LINE 4: FROM sq_ast WHERE assetid = 7

Я могу заставить его работать, выполнив

SELECT assetid, type_code, version, name, short_name, status, languages,
charset, force_secure, created, created_userid, updated, updated_userid,
published, published_userid, status_changed, status_changed_userid
FROM sq_ast WHERE assetid = '7'

Обратите внимание на цитирование 7 в предложении WHERE ...

Я развертываю огромное приложение и не могу переписать ядро ​​... точно так же я не хочу рисковать изменением типа столбца ...

Я не эксперт Postgres ... пожалуйста, помогите ...

Есть ли вариант для строгого приведения столбцов ???

1 Ответ

6 голосов
/ 19 мая 2010

Postgresql более строго напечатан в последних версиях, и это хорошо. Если assetid - это VARCHAR, то вы не можете сравнить его с целым числом (я полагаю, что с 8.4).

В целом (не только в Postgresql, не только в дизайне базы данных) неправильно смешивать эти типы: числовые типы данных должны использоваться для реальных числовых полей, а не для строк, которые просто состоят из цифр.

Например, счет-фактура "номер" или номер кредитной карты, как правило, должны представляться не как "номер", а как строка.

Иногда, однако, решение неясно (например, номера документов).

Некоторые критерии, которые могут помочь:

  • Вы потенциально заинтересованы в арифметике со своими значениями (сумма, вычитание)? Будет ли это хотя бы иметь смысл? Тогда это число .

  • Должны ли нули слева быть сохранены или считаться актуальными? (следует ли считать «07» отличным от «7»?) Тогда это строка .

В зависимости от того, как вы ответите на эти вопросы в своем сценарии (существует ли сборка, начинающаяся с 0? Может ли быть какой-либо не числовой символ? Это серийный номер?), Вы можете подумать об изменении типа поля или (более вероятно в вашем сценарии) выполнить приведение в предпочтительном направлении:

   SELECT... FROM sq_ast WHERE assetid::integer = 7

(если вы решите, что поле числовое) или в другом месте

   SELECT... FROM sq_ast WHERE assetid = '7'

Нет глобальных настроек для возврата к старому поведению и принудительного неявного приведения типов символов, AFAIK.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...