Re: Casts in 7.0 vs 6.5 (was Re: [SQL] 7.0beta bug (or feature)?)
| От | Kyle Bateman |
|---|---|
| Тема | Re: Casts in 7.0 vs 6.5 (was Re: [SQL] 7.0beta bug (or feature)?) |
| Дата | |
| Msg-id | 38C67E39.DA7EE8A5@actarg.com обсуждение исходный текст |
| Ответ на | 7.0beta bug (or feature)? (Kyle Bateman <kyle@actarg.com>) |
| Список | pgsql-sql |
Tom Lane wrote:
>
> I am not sure whether this should be regarded as a bug or a feature.
> On the one hand you could argue that ambiguous casts are a bad thing,
> but on the other hand, if text(foo) works, why shouldn't foo::text work?
>
> One thing to realize while considering whether to change this is that if
> we generalize the behavior of casts, we may also affect the behavior of
> implicit casts, such as the one applied to convert supplied data in an
> INSERT or UPDATE to the target column type. This could result in loss
> of error detection capability. Currently, both 6.5 and 7.0 do this:
>
> regression=# create table foo(f1 text);
> CREATE
> regression=# insert into foo values('now'::date);
> ERROR: Attribute 'f1' is of type 'text' but expression is of type 'date'
> You will need to rewrite or cast the expression
>
> but if we allow datevalue::text to work, then (barring still more
> pushups in the code) the above will be accepted. Should it be?
>
> Comments anyone?
>
What if you could to a "set AutoCasting=yes" just as you might set the
datestyle variable. Then the DBA could decide whether type mismatches
should be quitely translated or reported?
Вложения
В списке pgsql-sql по дате отправления: