Re: [Fwd: [TESTERS] Numerics of diffrent scales Raises Type Mismatch Error in a Set Returning Function]
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [Fwd: [TESTERS] Numerics of diffrent scales Raises Type Mismatch Error in a Set Returning Function] |
| Дата | |
| Msg-id | 6645.1267926354@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | [Fwd: [TESTERS] Numerics of diffrent scales Raises Type Mismatch Error in a Set Returning Function] (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: [Fwd: [TESTERS] Numerics of diffrent scales Raises Type
Mismatch Error in a Set Returning Function]
|
| Список | pgsql-bugs |
Josh Berkus <josh@agliodbs.com> writes:
> I tested Noel's test case and verified that it does, in fact, break.
> And functions on 8.4.
This is an intentional change, as the previous behavior is obviously
wrong. Try putting in a value that does not conform to numeric(14,2),
such as 42.7777. It doesn't get converted.
In some future version we might want to think about applying actual data
conversions in such contexts, but right now the tuple conversion code
just insists on exact datatype matches.
The reason for the behavioral change is that plpgsql, which formerly
had really crummy tuple conversion logic with a whole bunch of other
deficiencies besides this one, now shares the logic used by
ConvertRowtypeExpr.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера