Re: Cast jsonb to numeric, int, float, bool

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cast jsonb to numeric, int, float, bool
Date: 2018-03-28 02:33:49
Message-ID: 20180328023349.GI1105@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-03-28 02:58:21 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Michael Paquier 2018-03-28 02:27:43 Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()