Interesting! I'd be curious as to what types of bugs were caused by these implicit casts..
Note 8.3 was in the days back before ORMs became popular, so "just write better SQL" was a perfectly decent solution to the problem back then. Now days, this requirement might make Postgres incompatible with certain ORMs out there, which is a bummer. I'm wondering if these ambiguities you speak of could be solved in other ways. Such as implicitly cast iff the intention is not ambiguous, otherwise raise some sort of "ambiguous" error or default to some behavior. Mike On Tue, Jan 28, 2014 at 2:46 PM, John R Pierce <pie...@hogranch.com> wrote: > On 1/28/2014 2:35 PM, Mike Christensen wrote: > >> This works. However, to agree with the original poster's point, if >> Postgres could be a little more forgiving about values that could be >> interpreted as correct (like an implicit cast between numeric and enum and >> string and enum) then we wouldn't have these issues.. >> > > it had more implicit casts prior to (I think) 8.3, but there were many > ambiguities where things could be interpreted to mean radically different > sorts of operations, so they tightened things up in 8.3+ (or was it 8.4+ ?) > > > > > -- > john r pierce 37N 122W > somewhere on the middle of the left coast > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
