On Mon, Mar 12, 2018 at 12:43:20PM -0400, Tom Lane wrote: > Another fundamental problem is that implicit casts mask mistakes. > If there's an implicit cast to numeric, that applies everywhere not > only where it was what you meant. For some context on this you might > go back to the archives around the time of 8.3, where we actually > removed a bunch of implicit casts because they led to too many > surprising behaviors. Restricting implicit casts to the same type > category is a rule-of-thumb for reducing the potential surprise > factor.
+1 to that. >> What would be other options, if not implicit cast? > > Explicit casts, ie (jsonvar->'fieldname')::numeric. Yeah, you have > to write a bit more, but you don't get surprised by the way the > parser interpreted your query. > > The other thing you can potentially do is use a variant operator > name, as we did for text output with ->>. But that doesn't scale > to very many result types, because it's impossible to choose > readily mnemonic operator names. So I'd stick with the casts. And +1 to that. Implicit casts are cool things when they don't cause a potential loss of precision, which could be equivalent to losing some data, so sticking with casts looks more acceptable to me, and I would vote to not move on with this patch. -- Michael
signature.asc
Description: PGP signature