Teodor Sigaev writes:
> Thanks for your idea, patch is attached
Looks mostly fine from here. A couple nitpicks:
* s/translable/translatable/
* Personally I'd try harder to make the lookup table constant, that is
+ static const struct
+ {
+ enum
1) Does this really pass muster from the translatability standpoint?
I doubt it.
Huh, I missed that.
I think you want the callers to look like
if (!JsonbExtractScalar(>root, ) || v.type != jbvNumeric)
cannotCastJsonbValue(v.type, "double precision");
where the
I wrote:
> 1) Does this really pass muster from the translatability standpoint?
> I doubt it.
After further thought about that, it seems that what we typically don't
try to translate is SQL-standard type names, that is, error messages
along the line of "blah blah blah type %s" are considered
Teodor Sigaev writes:
> Does anybody have an objections to patch?
1) Does this really pass muster from the translatability standpoint?
I doubt it. I'd expect the translation of "cannot cast jsonb string
to int4" to use a translated equivalent of "string", but this code will
How about "cannot cast jsonb $json_type to $sql_type" where $json_type
is the type inside the jsonb (e.g. string, number, boolean, array,
object)?
Yes, that sounds pretty good.
Does anybody have an objections to patch?
--
Teodor Sigaev E-mail:
On Fri, Mar 30, 2018 at 11:21 AM, Dagfinn Ilmari Mannsåker
wrote:
> How about "cannot cast jsonb $json_type to $sql_type" where $json_type
> is the type inside the jsonb (e.g. string, number, boolean, array,
> object)?
Yes, that sounds pretty good.
--
Robert Haas
Hello Teodor,
> > Agree, something like "could not convert jsonb value to boolean type. jsonb
> > value must be scalar boolean type"?
>
> I checked what error messages are used currently:
>
> ```
> # select 123::int4::jsonb;
> ERROR: cannot cast type integer to jsonb
> LINE 1: select
Hello Teodor,
> For completeness it's possible to add direct cast from numeric/boolean types
> to jsonb. Then such casts will be mutual.
+1. I see no reason why we can't have int4 -> jsonb or bool -> jsonb
casts.
> Agree, something like "could not convert jsonb value to boolean type. jsonb
>
I would like to complain about this patch. First, I think that it
would've been a better idea to use functions for this rather than
operators, because now ::text does something totally unlike what ::int
does, and that's confusing. If we had json_to_WHATEVER for various
values of WHATEVER then
Hello Robert,
> I would like to complain about this patch. First, I think that it
> would've been a better idea to use functions for this rather than
> operators, because now ::text does something totally unlike what ::int
> does, and that's confusing.
This is not entirely accurate. ::text
On Thu, Mar 29, 2018 at 9:35 AM, Teodor Sigaev wrote:
> Thanks for everyone, pushed with some editorization
I would like to complain about this patch. First, I think that it
would've been a better idea to use functions for this rather than
operators, because now ::text does
Thanks for everyone, pushed with some editorization
Teodor Sigaev wrote:
I think, it should support from/to numeric/bool/text only. If we want to have
casts to from numeric to other numeric types then it should be full set (int2,
int4, int8, float4, float8).
I was too optimistic about
I think, it should support from/to numeric/bool/text only. If we want to have
casts to from numeric to other numeric types then it should be full set (int2,
int4, int8, float4, float8).
I was too optimistic about casting to/from text. It already exists and it works
by differ way from
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
Hi!
I took a look on patch and it seems to me it looks both incomplete and
oveflowing. It suggests cast from numeric and bool, but for numeric it suggests
only numeric, int4 and int8. This choice looks irrational.
I think, it should support from/to numeric/bool/text only. If we want to have
Hello everyone,
> Since this patch was updated after being set a Ready for Committer and
> there appear to be some open questions, I have set it to Needs Review.
I decided to take a look.
The patch didn't apply after changes made in fd1a421f, but I fixed that.
Also there were no tests. I fixed
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes:
> 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
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.
>
Nikita Glukhov writes:
> On 01.03.2018 11:19, Darafei "Komяpa" Praliaskouski wrote:
>> I would expect some casts to be implicit, so that chaining with other
>> functions is possible:
> I think that only cast to a numeric type can be made implicit, because
> it does not
On 2/28/18 7:12 PM, Nikita Glukhov wrote:
> On 01.03.2018 00:43, Darafei Praliaskouski wrote:
>>
>> The new status of this patch is: Ready for Committer
>
> Attached new version of the patch in which I removed duplicated code
> using new subroutine JsonbExtractScalar(). I am not sure what is
On 01.03.2018 11:19, Darafei "Komяpa" Praliaskouski wrote:
> Attached new version of the patch in which I removed duplicated code
using new subroutine JsonbExtractScalar(). I am not sure what is
better to do when a JSON item has an unexpected type: to throw an
error or to return SQL NULL.
> Attached new version of the patch in which I removed duplicated code
using new subroutine JsonbExtractScalar(). I am not sure what is better to
do when a JSON item has an unexpected type: to throw an error or to return
SQL NULL. Also JSON nulls could be converted to SQL NULLs.
I would expect
On 01.03.2018 00:43, Darafei Praliaskouski wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
We're using
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
We're using this patch and like it a lot.
We store a lot of
01.02.2017 17:41, Anastasia Lubennikova:
Now the simplest way to extract booleans and numbers from json/jsonb
is to cast it
to text and then cast to the appropriate type:
postgres=# select 'true'::jsonb::text::bool;
bool
--
t
postgres=# select '1.0'::jsonb::text::numeric;
numeric
25 matches
Mail list logo