From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Зотов Роман <zotov(at)oe-it(dot)ru>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Prefered Types |
Date: | 2011-05-04 13:49:38 |
Message-ID: | 9904.1304516978@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <jim(at)nasby(dot)net> writes:
> Which begs the question... why do we allow on assignment casting of a float to an int?
Because the SQL standard requires it.
In any case, the user's intent in such a case is perfectly clear.
The reasons for not allowing assignment casts to happen in expression
contexts are (1) it would often provide us with too many ways to resolve
an operator or function call, leading to "ambiguous operator" failures;
(2) it would be surprising for the parser to silently choose a cast that
causes information loss. Neither of these arguments applies to "assign
this value to an integer column".
It's true that if you have exactly one function named f, and it takes an
int, then f(float) could be considered clear and unambiguous. But
designing this behavior around only the easy cases is not going to work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-04 14:02:15 | Re: Unlogged vs. In-Memory |
Previous Message | Jim Nasby | 2011-05-04 12:48:49 | Re: Prefered Types |