Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length limit?

> Now that I've modified the code so that casting to a specific length
> actually works --- ie you can do
>     x :: 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.

Yes, this is distressing.

> 
> 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 that
>     create 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.

Sounds good to me.
--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026