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
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() |