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

From: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-12 15:24:36
Message-ID: CAC8Q8t++bOLPHqb1ui5Gg+w0vuhEoAg7B__1XpgT8xzi4MF2sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> I hadn't been following this thread particularly, but I happened to notice
> this bit, and I thought I'd better pop up to say No Way. There will be
> *no* implicit casts from json to any numeric type. We have learned the
> hard way that implicit cross-category casts are dangerous.
>

I can see how a cast from text can be problematic, especially before the
'unknown' type.

But what would be the scenario of failure if we have an implicit cast from
jsonb datatype (that likely already parsed the number internally, or knows
it holds non-numeric value) to numeric, that returns an error if it's
unable to perform the conversion?

The issue I think is that jsonb is special because it is in fact container.
We've got dot-notation to unpack things from composite TYPE, and we've got
arrow-notation to unpack things from jsonb, but such unpacking cannot take
part in further computations, even though it's visually compatible.

What would be other options, if not implicit cast?

Darafei Praliaskouski,
GIS Engineer / Juno Minsk

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2018-03-12 15:26:36 Re: Jsonb transform for pl/python
Previous Message Peter Eisentraut 2018-03-12 15:21:36 Re: JIT compiling with LLVM v11