Should cast to CHAR or NUMERIC enforce default length limit?
От | Tom Lane |
---|---|
Тема | Should cast to CHAR or NUMERIC enforce default length limit? |
Дата | |
Msg-id | 9864.948296118@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length
limit?
|
Список | pgsql-hackers |
Now that I've modified the code so that casting to a specific length actually works --- ie you can dox :: char(7)CAST (y AS numeric(40,6)) and get the expected results --- I am starting to worry that there may be unwanted side-effects. The reason is that the system by default interprets "char" as "char(1)" and "numeric" as "numeric(30,6)". So if you just write "x::char" you will now get truncation to one character, which did not use to happen. Another distressing example is regression=# select '123456789012345678901234567890.12'::numeric; ERROR: overflow on numeric ABS(value) >= 10^29 for field with precision 30 scale 6 which I think is arguably a violation of the SQL standard --- it says pretty clearly that the precision and scale of a numeric constant are whatever is implicit in the number of digits. I am inclined to think that in the context of a cast, we shouldn't enforce a coercion to default length, but should only coerce if a length is explicitly specified. This would change the behavior of "x::char" back to what it was. I think this could be done by having gram.y insert -1 as the default typmod for a "char" or "numeric" Typename. The rest of the system already interprets such a typmod as specifying no particular length constraint. Then, to preserve the rule thatcreate table foo (bar char); creates a char(1) field, analyze.c would have to be responsible for inserting the appropriate default length in place of -1 when processing a column definition. Comments? Better ideas? regards, tom lane
В списке pgsql-hackers по дате отправления: