Re: - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re:
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E84@m0114.s-mxs.net
Whole thread Raw
In response to  (ljguo_1234 <ljguo_1234@sina.com>)
List 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 by date:

Previous
From: Antti Haapala
Date:
Subject: Re: Multicolumn foreign keys need useless unique indices?
Next
From: "Shridhar Daithankar"
Date:
Subject: [OT]Physical sites handling large data