| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | pgsql-hackers(at)postgreSQL(dot)org | 
| Subject: | Should cast to CHAR or NUMERIC enforce default length limit? | 
| Date: | 2000-01-19 15:35:18 | 
| Message-ID: | 9864.948296118@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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.
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.
Comments? Better ideas?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2000-01-19 15:40:11 | Re: Status on 7.0 | 
| Previous Message | Thomas Lockhart | 2000-01-19 15:27:41 | Re: Status on 7.0 |