> On Mon, Nov 18, 2024 at 08:23:52AM GMT, Andy Fan wrote:
>
> >> > I imagined you'd the patch should create a SupportRequestSimplify
> >> > support function for jsonb_numeric() that checks if the input
> >> > expression is an OpExpr with funcid of jsonb_object_field(). All you
> >> > do then is di
Hi Dmitry,
>> On Thu, Sep 12, 2024 at 03:03:18AM GMT, Andy Fan wrote:
>>
>> > I imagined you'd the patch should create a SupportRequestSimplify
>> > support function for jsonb_numeric() that checks if the input
>> > expression is an OpExpr with funcid of jsonb_object_field(). All you
>> > do th
> On Thu, Sep 12, 2024 at 03:03:18AM GMT, Andy Fan wrote:
>
> > I imagined you'd the patch should create a SupportRequestSimplify
> > support function for jsonb_numeric() that checks if the input
> > expression is an OpExpr with funcid of jsonb_object_field(). All you
> > do then is ditch the cast
Hello David,
Thanks for checking this!
> There's a lot of complexity in the v18 patch that I don't understand
> the need for.
>
> I imagined you'd the patch should create a SupportRequestSimplify
> support function for jsonb_numeric() that checks if the input
> expression is an OpExpr with
On Wed, 17 Apr 2024 at 17:17, Andy Fan wrote:
> rebase to the latest master again.
There's a lot of complexity in the v18 patch that I don't understand
the need for.
I imagined you'd the patch should create a SupportRequestSimplify
support function for jsonb_numeric() that checks if the input
ex
Andy Fan writes:
> Here is latest version, nothing changed besides the rebase to the latest
> master. The most recent 3 questions should be addressed.
>
> - The error message compatible issue [1] and the Peter's answer at [2].
> - Peter's new question at [2] and my answer at [3].
>
> Any effrot
Here is latest version, nothing changed besides the rebase to the latest
master. The most recent 3 questions should be addressed.
- The error message compatible issue [1] and the Peter's answer at [2].
- Peter's new question at [2] and my answer at [3].
Any effrot to move this patch ahead is wel
>> But I have a different question about this patch set. This has some
>> overlap with the JSON_VALUE function that is being discussed at
>> [0][1]. For example, if I apply the patch
>> v39-0001-Add-SQL-JSON-query-functions.patch from that thread, I can run
>>
>> select count(*) from tb where js
Peter Eisentraut writes:
> On 09.02.24 10:05, Andy Fan wrote:
>> 2. Where is the current feature blocked for the past few months?
>> It's error message compatible issue! Continue with above setup:
>> master:
>> select * from tb where (a->'b')::numeric > 3::numeric;
>> ERROR: cannot cast jsonb
On 09.02.24 10:05, Andy Fan wrote:
2. Where is the current feature blocked for the past few months?
It's error message compatible issue! Continue with above setup:
master:
select * from tb where (a->'b')::numeric > 3::numeric;
ERROR: cannot cast jsonb string to type numeric
select * from tb
Hi,
Here is the update of this patch.
1. What is it for?
commit f7b93acc24b4a152984048fefc6d71db606e3204 (HEAD -> jsonb_numeric)
Author: yizhi.fzh
Date: Fri Feb 9 16:54:06 2024 +0800
Improve the performance of Jsonb numeric/bool extraction.
JSONB object uses a binary compatible
On Sun, Jan 7, 2024 at 3:26 PM Andy Fan wrote:
>
>
> Hi,
>
> > hi.
> > you don't need to change src/include/catalog/catversion.h
> > as mentioned in https://wiki.postgresql.org/wiki/Committing_checklist
> > Otherwise, cfbot will fail many times.
>
> Thanks for the wiki.
>
> I checked the wiki and
Hi,
> hi.
> you don't need to change src/include/catalog/catversion.h
> as mentioned in https://wiki.postgresql.org/wiki/Committing_checklist
> Otherwise, cfbot will fail many times.
Thanks for the wiki.
I checked the wiki and search "catversion", the only message I got is:
"Consider the need
hi.
you don't need to change src/include/catalog/catversion.h
as mentioned in https://wiki.postgresql.org/wiki/Committing_checklist
Otherwise, cfbot will fail many times.
+typedef enum JsonbValueTarget
+{
+ JsonbValue_AsJsonbValue,
+ JsonbValue_AsJsonb,
+ JsonbValue_AsText
+} JsonbValueTarget;
ch
Chapman Flack writes:
(This is Andy Fan and I just switch to my new email address).
Hi Chap,
Thanks for alway keep an eye on this!
> Adding this comment via the CF app so it isn't lost, while an
> improperly-interpreted-DKIM-headers issue is still preventing me from
> mailing directly to -hac
On Wed, Nov 1, 2023 at 9:18 AM Chapman Flack wrote:
> So, it would not have been my choice to assign RfC status before getting to a
> resolution on that.
It's up to the reviewer (here Chapman), not the author, to decide
whether to set it to RfC. I've set the status to "needs review".
Adding this comment via the CF app so it isn't lost, while an
improperly-interpreted-DKIM-headers issue is still preventing me from mailing
directly to -hackers.
It was my view that the patch was getting close by the end of the last
commitfest, but still contained a bit of a logic wart made nec
Hi,
I am feeling this topic has been well discussed and the only pending
issues are below, it would be great that any committer can have a
look at these, so I mark this entry as "Ready for Committer".
Things are not addressed yet:
> 1. the error message handling.
>
You can check [1] for more
> Is there a reason not to transform the _tz flavors of
>> jsonb_path_query and jsonb_path-query_first?
>>
>
> I misunderstood the _tz flavors return timestamp, after some deep
> reading of these functions, they just work at the comparisons part.
> so I will add them in the following version.
>
_
On Thu, Sep 14, 2023 at 5:18 AM Chapman Flack wrote:
> On 2023-09-04 10:35, Andy Fan wrote:
> > v13 attached. Changes includes:
> >
> > 1. fix the bug Jian provides.
> > 2. reduce more code duplication without DirectFunctionCall.
> > 3. add the overlooked jsonb_path_query and jsonb_path_qu
On 2023-09-04 10:35, Andy Fan wrote:
v13 attached. Changes includes:
1. fix the bug Jian provides.
2. reduce more code duplication without DirectFunctionCall.
3. add the overlooked jsonb_path_query and jsonb_path_query_first as
candidates
Apologies for the delay. I like the way this is
>
>
> based on v13.
> IMHO, it might be a good idea to write some comments on
> jsonb_object_field_internal. especially the second boolean argument.
> something like "some case, we just want return JsonbValue rather than
> Jsonb. to return JsonbValue, make as_jsonb be false".
>
OK, I will proposa
On Mon, Sep 4, 2023 at 10:35 PM Andy Fan wrote:
>
> Hi,
>
> v13 attached. Changes includes:
>
> 1. fix the bug Jian provides.
> 2. reduce more code duplication without DirectFunctionCall.
> 3. add the overlooked jsonb_path_query and jsonb_path_query_first as
> candidates
>
>
> --
> Best Re
Hi,
v13 attached. Changes includes:
1. fix the bug Jian provides.
2. reduce more code duplication without DirectFunctionCall.
3. add the overlooked jsonb_path_query and jsonb_path_query_first as
candidates
--
Best Regards
Andy Fan
v13-0001-optimize-casting-jsonb-to-a-given-type.patch
D
Hi Jian,
SELECT (test_json -> 'field1')::int4 FROM test_jsonb WHERE json_type
> = 'object';
> -ERROR: cannot cast jsonb string to type integer
> +ERROR: unknown jsonb type: 1125096840
>
Thanks for the report! The reason is I return the address of a local
variable.
jsonb_object_field_start(PG
I think the last patch failed. I am not 100% sure.
https://cirrus-ci.com/task/5464366154252288
says "Created 21 hours ago", I assume the latest patch.
the diff in Artifacts section. you can go to
testrun/build/testrun/regress/regress/regression.diffs
diff -U3 /tmp/cirrus-ci-build/src/test/regress
> An incompatible issue at error message level is found during test:
> create table jb(a jsonb);
> insert into jb select '{"a": "a"}'::jsonb;
> select (a->'a')::int4 from jb;
>
> master: ERROR: cannot cast jsonb string to type *integer*
> patch: ERROR: cannot cast jsonb string to type *numeric
Hi Chap,
The v11 attached, mainly changes are:
1. use the jsonb_xx_start and jsonb_finish_numeric style.
2. improve the test case a bit.
It doesn't include:
1. the jsonb_finish_text function, since we have a operator ->> for text
already and the performance for it is OK and there is no cast en
On 2023-08-30 00:47, Andy Fan wrote:
see what it is. Suppose the original query is:
numeric(jsonb_object_field(v_jsonb, text)) -> numeric.
...
However the declared type of jsonb_object_field_type is:
jsonb_object_field_type(internal, jsonb, text) -> internal.
So the situation is: b). We retu
(Sorry for leaving this discussion for such a long time, how times fly!)
On Sun, Aug 27, 2023 at 6:28 AM Chapman Flack wrote:
> On 2023-08-22 08:16, Chapman Flack wrote:
> > On 2023-08-22 01:54, Andy Fan wrote:
> >> After we label it, we will get error like this:
> >>
> >> select (a->'a')::int4
On 2023-08-22 08:16, Chapman Flack wrote:
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel node is being appl
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel node is being applied at the result. The idea,
of course, was
>
>
>>> Perhaps one of the more senior developers will chime in, but to me,
>>> leaving out the relabel nodes looks more like "all of PostgreSQL's
>>> type checking happened before the SupportRequestSimplify, so nothing
>>> has noticed that we rewrote the tree with mismatched types, and as
>>> long
（Just relalized this was sent to chap in private, resent it again).
On Mon, Aug 21, 2023 at 6:50 PM Andy Fan wrote:
>
>
> On Mon, Aug 21, 2023 at 11:19 AM Chapman Flack
> wrote:
>
>> On 2023-08-20 21:31, Andy Fan wrote:
>> > Highlighting the user case of makeRelableType is interesting! But usin
>
>
> Interestingly, when I relabel both places, like this:
>
> Oid targetOid = fexpr->funcresulttype;
> Const *target = makeConst(
>OIDOID, -1, InvalidOid, sizeof(Oid),
>ObjectIdGetDatum(targetOid), false, true);
> RelabelType *rTarget = makeRelabelType((Expr *)ta
On 2023-08-20 21:31, Andy Fan wrote:
Highlighting the user case of makeRelableType is interesting! But using
the Oid directly looks more promising for this question IMO, it looks
like:
"you said we can put anything in this arg, so I put an OID const
here",
seems nothing is wrong.
Perhaps on
On Sat, Aug 19, 2023 at 3:09 AM Chapman Flack wrote:
> On 2023-08-18 14:50, Chapman Flack wrote:
> > Now, my guess is EXPLAIN is complaining when it sees the Const
> > of type internal, and doesn't know how to show that value.
> > Perhaps makeRelabelType is the answer there, too: what if the
> >
On 2023-08-18 15:08, Chapman Flack wrote:
But I don't know that adding relabel nodes wouldn't still be
the civilized thing to do.
Interestingly, when I relabel both places, like this:
Oid targetOid = fexpr->funcresulttype;
Const *target = makeConst(
OIDOID, -1, InvalidOid, siz
On 2023-08-18 14:50, Chapman Flack wrote:
Now, my guess is EXPLAIN is complaining when it sees the Const
of type internal, and doesn't know how to show that value.
Perhaps makeRelabelType is the answer there, too: what if the
Const has Oid type, so EXPLAIN can show it, and what's inserted
as the
On 2023-08-18 03:41, Andy Fan wrote:
I just have
a quick hack on this, and crash happens at the simplest case.
If I build from this patch, this test:
SELECT (test_json -> 0)::int4, test_json -> 0 FROM test_jsonb WHERE
json_type = 'scalarint';
fails like this:
Program received signal SIGSEG
> because as long as it has parameters declared internal,
> no SQL can ever call it.
I was confused about the difference between anyelement and
internal, and I want to know a way to create a function which
is disallowed to be called by the user. Your above words
resolved two questions of mine!
On Fri, Aug 18, 2023 at 10:55 AM Chapman Flack wrote:
>
>
> Again, all of that complication stems from the choice to use the
> anyelement return type and rely on polymorphic type resolution
> to figure the oid out, when we already have the oid to begin with
> and the oid is all we want.
>
you wan
On 2023-08-17 21:14, Andy Fan wrote:
The idea of an 'internal' return type with no 'internal' parameter
was quickly and rightly shot down.
Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:
Well, the reason "internal return ty
Hi Chapman,
Thanks for the review!
The idea of an 'internal' return type with no 'internal' parameter
> was quickly and rightly shot down.
Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:
anyelement fn(anyment in);
if the ex
On 2023-08-17 05:07, Andy Fan wrote:
Thanks for the review, v9 attached!
From the earliest iterations of this patch, I seem to recall
a couple of designs being considered:
In one, the type-specific cast function would only be internally
usable, would take a type oid as an extra parameter (sup
Hi jian:
On Thu, Aug 17, 2023 at 12:32 AM jian he
wrote:
> On Wed, Aug 16, 2023 at 2:28 PM Andy Fan wrote:
> >
> > update with the correct patch..
>
> regression=# select proname, pg_catalog.pg_get_function_arguments(oid)
> from pg_proc
> where proname = 'jsonb_extract_path_type';
> p
On Wed, Aug 16, 2023 at 2:28 PM Andy Fan wrote:
>
> update with the correct patch..
regression=# select proname, pg_catalog.pg_get_function_arguments(oid)
from pg_proc
where proname = 'jsonb_extract_path_type';
proname | pg_get_function_arguments
update with the correct patch..
v8-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
On Tue, Aug 15, 2023 at 1:24 PM Pavel Stehule
wrote:
> Hi
>
> út 15. 8. 2023 v 5:24 odesílatel Andy Fan
> napsal:
>
>>
>>> jsonb_extract_xx_type just cares about the argtype, but
>>> 'explain select xx' will still access the const->constvalue.
>>> const->constvalue is 0 which is set by makeNul
út 15. 8. 2023 v 9:05 odesílatel Andy Fan napsal:
>
>
>> a) effectiveness. The ending performance should be similar like your
>> current patch, but without necessity to use planner support API.
>>
>
> So the cost is we need to create a new & different framework.
>
yes, it can be less work, code
>
> a) effectiveness. The ending performance should be similar like your
> current patch, but without necessity to use planner support API.
>
So the cost is we need to create a new & different framework.
>
>
b) because you can write only var := j->'f', and plpgsql forces cast
> function execution
út 15. 8. 2023 v 8:04 odesílatel Andy Fan napsal:
>
>> My idea of an ideal solution is the introduction of the possibility to
>> use "any" pseudotype as return type with possibility to set default return
>> type. Now, "any" is allowed only for arguments. The planner can set the
>> expected type w
>
>
> My idea of an ideal solution is the introduction of the possibility to use
> "any" pseudotype as return type with possibility to set default return
> type. Now, "any" is allowed only for arguments. The planner can set the
> expected type when it knows it, or can use the default type.
>
> so f
út 15. 8. 2023 v 7:23 odesílatel Pavel Stehule
napsal:
> Hi
>
> út 15. 8. 2023 v 5:24 odesílatel Andy Fan
> napsal:
>
>>
>>> jsonb_extract_xx_type just cares about the argtype, but
>>> 'explain select xx' will still access the const->constvalue.
>>> const->constvalue is 0 which is set by makeN
Hi
út 15. 8. 2023 v 5:24 odesílatel Andy Fan napsal:
>
>> jsonb_extract_xx_type just cares about the argtype, but
>> 'explain select xx' will still access the const->constvalue.
>> const->constvalue is 0 which is set by makeNullConst currently,
>> and it is ok for the current supported type.
>
>
>
> jsonb_extract_xx_type just cares about the argtype, but
> 'explain select xx' will still access the const->constvalue.
> const->constvalue is 0 which is set by makeNullConst currently,
> and it is ok for the current supported type.
>
The exception is numeric data type, the constvalue can't
On Mon, Aug 14, 2023 at 10:10 PM Tom Lane wrote:
> Chapman Flack writes:
> > Providing a function with return type declared internal but
> > with no parameter of that type is not good,
>
> Not so much "not good" as "absolutely, positively WILL NOT HAPPEN".
Chap is pretty nice to others:).
>
Chapman Flack writes:
> Providing a function with return type declared internal but
> with no parameter of that type is not good,
Not so much "not good" as "absolutely, positively WILL NOT HAPPEN".
> because then a
> user could, in principle, call it and obtain a value of
> 'internal' type, and
On 2023-08-14 03:06, Andy Fan wrote:
We'd still have functions like jsonb_field_as_numeric() under the
hood, but there's not an expectation that users call them explicitly.
To avoid the lots of functions like jsonb_field_as_int2/int4, I defined
Datum jsonb_object_field_type(.., Oid target_oid)
po 14. 8. 2023 v 11:17 odesílatel Andy Fan
napsal:
>
>> you cannot to use type as parameter. There should be some typed value -
>> like
>>
>> jsonb_object_field, '{"a":10}', 'a', NULL::int)
>>
>> and return type should be anyelement.
>>
>>
> So could we get the inputted type in the body of jsonb_
>
>
> you cannot to use type as parameter. There should be some typed value -
> like
>
> jsonb_object_field, '{"a":10}', 'a', NULL::int)
>
> and return type should be anyelement.
>
>
So could we get the inputted type in the body of jsonb_object_field?
I guess no. IIUC, our goal will still be misse
po 14. 8. 2023 v 9:06 odesílatel Andy Fan napsal:
>
>> We'd still have functions like jsonb_field_as_numeric() under the
>> hood, but there's not an expectation that users call them explicitly.
>>
>
> To avoid the lots of functions like jsonb_field_as_int2/int4, I defined
> Datum jsonb_object_fie
>
>
> We'd still have functions like jsonb_field_as_numeric() under the
> hood, but there's not an expectation that users call them explicitly.
>
To avoid the lots of functions like jsonb_field_as_int2/int4, I defined
Datum jsonb_object_field_type(.., Oid target_oid) at last, so the
function must
Hi:
On Mon, Aug 7, 2023 at 7:51 PM Andy Fan wrote:
> Hi Jian:
>
> Thanks for the review!
>
> compared with jsonb_numeric. I am wondering if you need a free *jb.
>> elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0));
>> says there two are not the same.
>>
>
> Thanks for pointing this ou
Hi Jian:
Thanks for the review!
compared with jsonb_numeric. I am wondering if you need a free *jb.
> elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0));
> says there two are not the same.
>
Thanks for pointing this out, I am not sure what to do right now.
Basically the question is th
Hi.
+Datum
+jsonb_object_field_type(PG_FUNCTION_ARGS)
+{
+ Jsonb*jb = PG_GETARG_JSONB_P(0);
+ text*key = PG_GETARG_TEXT_PP(1);
+ Oid targetOid = PG_GETARG_OID(2);
compared with jsonb_numeric. I am wondering if you need a free *jb.
elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0
Hi Pavel:
Thanks for the code level review!
>
> I am looking on your patch, and the message
>
> +
> + default:
> + elog(ERROR, "cast jsonb field to %d is not supported.", targetOid);
>
> is a little bit messy. This case should not be possible, because it is
> filtered by jsonb_cast_is_optimized.
Hi
po 7. 8. 2023 v 5:04 odesílatel Andy Fan napsal:
> Hi:
>
>
>> For all the people who are interested in this topic, I will post a
>> planner support function soon, you can check that then.
>>
>>
> The updated patch doesn't need users to change their codes and can get
> better performance. Tha
Hi:
> For all the people who are interested in this topic, I will post a
> planner support function soon, you can check that then.
>
>
The updated patch doesn't need users to change their codes and can get
better performance. Thanks for all the feedback which makes things better.
To verify ther
On 2023-08-03 23:55, Andy Fan wrote:
> The double quotes look weird to me. but it looks like a common
> situation.
>
> select numeric('1'::int); -- failed.
> select "numeric"('1'::int); -- ok.
It arises when you have an object (type, function, cast, whatever) whose
name in the catalog is the sa
Hi Tom:
On Fri, Aug 4, 2023 at 3:13 AM Tom Lane wrote:
> Andy Fan writes:
> >> If you use explicit cast, then the code should not be hard, in the
> >> rewrite stage all information should be known.
>
> > Can you point to me where the code is for the XML stuff?
>
> I think Pavel means XMLTABLE,
Hi:
>
> can confirm the patch's jsonb_object_field_numeric is faster than
> pg_catalog."numeric"(jsonb).
>
Thanks for the confirmation.
>
> This function is not easy to find out...
>
> select jsonb_numeric(jsonb'{"a":11}'->'a'); --fail
>
jsonb_numeric is a prosrc rather than a proname, that's
čt 3. 8. 2023 v 16:27 odesílatel Andy Fan napsal:
> Hi:
>
>
>> If you use explicit cast, then the code should not be hard, in the
>> rewrite stage all information should be known.
>>
>
> Can you point to me where the code is for the XML stuff? I thought
> this is a bad idea but I may accept it
On Thu, Aug 3, 2023 at 6:04 PM Matthias van de Meent
wrote:
>
>
> Is it? Detoasting only happens if the argument was toasted, and I have
> serious doubts that the result of (a->'a') will be toasted in our
> current system. Sure, we do need to allocate an intermediate result,
> but that's in a temp
Andy Fan writes:
>> If you use explicit cast, then the code should not be hard, in the
>> rewrite stage all information should be known.
> Can you point to me where the code is for the XML stuff?
I think Pavel means XMLTABLE, which IMO is an ugly monstrosity of
syntax --- but count on the SQL co
Hi:
> If you use explicit cast, then the code should not be hard, in the
> rewrite stage all information should be known.
>
Can you point to me where the code is for the XML stuff? I thought
this is a bad idea but I may accept it if some existing code does
such a thing already. "such thing"
Hi
čt 3. 8. 2023 v 15:23 odesílatel Andy Fan napsal:
> Hi:
>
>
>> More, I believe so lot of people uses more common syntax, and then this
>> syntax should to have good performance - for jsonb - (val->'op')::numeric
>> works, and then there should not be performance penalty, because this
>> synta
Hi:
On Thu, Aug 3, 2023 at 8:34 PM Chapman Flack wrote:
> On 2023-08-03 03:53, Andy Fan wrote:
> > I didn't realize timetime types are binary compatible with SQL,
> > so maybe we can have some similar optimization as well.
> > (It is a pity that timestamp(tz) are not binary, or else we may
> > j
Hi:
> More, I believe so lot of people uses more common syntax, and then this
> syntax should to have good performance - for jsonb - (val->'op')::numeric
> works, and then there should not be performance penalty, because this
> syntax will be used in 99%.
>
This looks like a valid opinion IMO,
On 2023-08-03 03:53, Andy Fan wrote:
I didn't realize timetime types are binary compatible with SQL,
so maybe we can have some similar optimization as well.
(It is a pity that timestamp(tz) are not binary, or else we may
just need one operator).
Not to veer from the thread, but something about
Hi:
>
> Yes, it's not great, but that's just how this works. We can't
> pre-specialize all possible operations that one might want to do in
> PostgreSQL - that'd be absurdly expensive for binary and initial
> database sizes.
>
Are any people saying we would pre-specialize all possible operators
On Wed, 2 Aug 2023 at 03:05, Andy Fan wrote:
>
> Hi Matthias:
>
> On Wed, Aug 2, 2023 at 7:33 AM Andy Fan wrote:
>>
>>
>>
>> On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent
>> wrote:
>>>
>>> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
>>> >
>>> > Hi:
>>> >
>>> > Currently if we want to e
Hi
čt 3. 8. 2023 v 9:53 odesílatel Andy Fan napsal:
> Hi Pavel:
>
> Thanks for the feedback.
>
> I don't like this solution because it is bloating operators and it is not
>> extra readable.
>>
>
> If we support it with cast, could we say we are bloating CAST? It is true
> that it is not extra
Hi Pavel:
Thanks for the feedback.
I don't like this solution because it is bloating operators and it is not
> extra readable.
>
If we support it with cast, could we say we are bloating CAST? It is true
that it is not extra readable, if so how about a->>'a' return text?
Actually
I can't gues
Hi
čt 3. 8. 2023 v 2:51 odesílatel Andy Fan napsal:
> Hi Jian:
>
>
>> return PointerGetDatum(v->val.numeric);
>> should be something like
>> PG_RETURN_NUMERIC(v->val.numeric);
>> ?
>>
>
> Thanks for this reminder, a new patch is attached. and commitfest
> entry is added as well[1]. For recordin
Hi Jian:
> return PointerGetDatum(v->val.numeric);
> should be something like
> PG_RETURN_NUMERIC(v->val.numeric);
> ?
>
Thanks for this reminder, a new patch is attached. and commitfest
entry is added as well[1]. For recording purposes, I compared the
new operator with all the existing operat
On Tue, Aug 1, 2023 at 12:39 PM Andy Fan wrote:
>
> Hi:
>
> Currently if we want to extract a numeric field in jsonb, we need to use
> the following expression: cast (a->>'a' as numeric). It will turn a numeric
> to text first and then turn the text to numeric again. See
> jsonb_object_field_text
Hi Matthias:
On Wed, Aug 2, 2023 at 7:33 AM Andy Fan wrote:
>
>
> On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent <
> boekewurm+postg...@gmail.com> wrote:
>
>> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
>> >
>> > Hi:
>> >
>> > Currently if we want to extract a numeric field in jsonb, we
On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
> >
> > Hi:
> >
> > Currently if we want to extract a numeric field in jsonb, we need to use
> > the following expression: cast (a->>'a' as numeric). It will
On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
>
> Hi:
>
> Currently if we want to extract a numeric field in jsonb, we need to use
> the following expression: cast (a->>'a' as numeric). It will turn a numeric
> to text first and then turn the text to numeric again.
Why wouldn't you use cast(a->'a
Hi:
Currently if we want to extract a numeric field in jsonb, we need to use
the following expression: cast (a->>'a' as numeric). It will turn a numeric
to text first and then turn the text to numeric again. See
jsonb_object_field_text and JsonbValueAsText. However the binary format
of numeric i
91 matches
Mail list logo
