Re:

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re:
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E84@m0114.s-mxs.net
обсуждение исходный текст
Ответ на  (ljguo_1234 <ljguo_1234@sina.com>)
Список pgsql-hackers
> > Sure it is.  The float=>int casts need to be made implicit, or we'll have
> > tons of problems like this.
>
> Well, yeah.  That did not seem to bother anyone last spring, when we
> were discussing tightening the implicit-casting rules.  Shall we
> abandon all that work and go back to "any available cast can
> be applied implicitly"?
>
> My vote is "tough, time to fix your SQL code".

I personally don't think that is good. SQL users are used to using implicit casts.
Other db's do handle them whereever possible. It is imho no answer to drop so many
implicit casts only because of the corner cases where it does not work.

What we imho really need is a runtime check that checks whether an implicit cast
caused a loss of precision and abort in that case only. That is what other db's do.

I thought that I voiced my opinion strong enough on this before, but I'll do it again,
I think we should allow a lot more implicit casts than are now in beta.
Especially in the numeric area.

I don't have any strong arguments (other than other db's can do it), but this is
my opinion.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Antti Haapala
Дата:
Сообщение: Re: Multicolumn foreign keys need useless unique indices?
Следующее
От: "Shridhar Daithankar"
Дата:
Сообщение: [OT]Physical sites handling large data