On Fri, Sep 6, 2024 at 1:34 PM Amit Langote wrote:
> On Fri, Sep 6, 2024 at 12:07 PM Amit Langote wrote:
> > On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wr
> > Pushed.
>
> Reverted 0002-0004 from both master and REL_17_STABLE due to BF failures.
>
> 0002-0003 are easily fixed by changing the new
On Fri, Sep 6, 2024 at 12:07 PM Amit Langote wrote:
> On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wrote:
> > On Tue, Sep 3, 2024 at 6:05 PM jian he wrote:
> > > On Mon, Sep 2, 2024 at 4:18 PM Amit Langote
> > > wrote:
> > > v2-0001 looks good to me.
> > > +-- Test JSON_TABLE() column deparsing
On Thu, Sep 5, 2024 at 9:58 PM Amit Langote wrote:
> On Tue, Sep 3, 2024 at 6:05 PM jian he wrote:
> > On Mon, Sep 2, 2024 at 4:18 PM Amit Langote wrote:
> > v2-0001 looks good to me.
> > +-- Test JSON_TABLE() column deparsing -- don't emit default ON ERROR /
> > EMPTY
> > +-- behavior
> > +EXP
Hi,
On Tue, Sep 3, 2024 at 6:05 PM jian he wrote:
> On Mon, Sep 2, 2024 at 4:18 PM Amit Langote wrote:
> v2-0001 looks good to me.
> +-- Test JSON_TABLE() column deparsing -- don't emit default ON ERROR / EMPTY
> +-- behavior
> +EXPLAIN VERBOSE SELECT * from JSON_TABLE('"a"', '$' COLUMNS (a text
On Mon, Sep 2, 2024 at 4:18 PM Amit Langote wrote:
>
> > See 0001.
> >
> >
> > See 0002.
> >
> > I'm also attaching 0003 to fix a minor annoyance that JSON_TABLE()
> > columns' default ON ERROR, ON EMPTY behaviors are unnecessarily
> > emitted in the deparsed output when the top-level ON ERROR be
On Fri, Aug 30, 2024 at 4:32 PM Amit Langote wrote:
> On Thu, Aug 22, 2024 at 12:44 PM Amit Langote wrote:
> > On Thu, Aug 22, 2024 at 11:02 jian he wrote:
> >> On Tue, Jul 30, 2024 at 12:59 PM Amit Langote
> >> wrote:
> >> > On Fri, Jul 26, 2024 at 11:19 PM jian he
> >> > wrote:
> >> > > {
On Thu, Aug 22, 2024 at 12:44 PM Amit Langote wrote:
> On Thu, Aug 22, 2024 at 11:02 jian he wrote:
>> On Tue, Jul 30, 2024 at 12:59 PM Amit Langote
>> wrote:
>> > On Fri, Jul 26, 2024 at 11:19 PM jian he
>> > wrote:
>> > > {
>> > > ...
>> > > /*
>> > > * For expression nodes that su
On Thu, Aug 22, 2024 at 11:02 jian he wrote:
> On Tue, Jul 30, 2024 at 12:59 PM Amit Langote
> wrote:
> >
> > Hi,
> >
> > On Fri, Jul 26, 2024 at 11:19 PM jian he
> wrote:
> > > On Fri, Jul 26, 2024 at 4:53 PM Amit Langote
> wrote:
> > > >
> > > >
> > > > Pushed 0003-0005 ahead of 0001-0002.
On Tue, Jul 30, 2024 at 12:59 PM Amit Langote wrote:
>
> Hi,
>
> On Fri, Jul 26, 2024 at 11:19 PM jian he wrote:
> > On Fri, Jul 26, 2024 at 4:53 PM Amit Langote
> > wrote:
> > >
> > >
> > > Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the
> > > weekend. Rebased for now.
>
Hi,
On Fri, Jul 26, 2024 at 11:19 PM jian he wrote:
> On Fri, Jul 26, 2024 at 4:53 PM Amit Langote wrote:
> >
> >
> > Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the
> > weekend. Rebased for now.
Pushed them now.
> {
> ...
> /*
> * For expression nodes that suppo
On Fri, Jul 26, 2024 at 4:53 PM Amit Langote wrote:
>
>
> Pushed 0003-0005 ahead of 0001-0002. Will try to push them over the
> weekend. Rebased for now.
{
...
/*
* For expression nodes that support soft errors. Should be set to NULL
* before calling ExecInitExprRec() if the call
On Fri, Jul 26, 2024 at 11:12 AM Amit Langote wrote:
> On Thu, Jul 25, 2024 at 11:16 PM Amit Langote wrote:
> > On Wed, Jul 24, 2024 at 3:25 PM jian he wrote:
> > > 2. domain over jsonb should fail just like domain over other types?
> > > RETURNING djs keep quotes DEFAULT '"11"' ON empty
> > > s
On Thu, Jul 25, 2024 at 11:16 PM Amit Langote wrote:
> On Wed, Jul 24, 2024 at 3:25 PM jian he wrote:
> > 2. domain over jsonb should fail just like domain over other types?
> > RETURNING djs keep quotes DEFAULT '"11"' ON empty
> > should fail as
> > ERROR: could not coerce ON EMPTY expression (
On Wed, Jul 24, 2024 at 3:25 PM jian he wrote:
> transformJsonFuncExpr we have:
> case JSON_QUERY_OP:
> if (jsexpr->returning->typid != JSONBOID || jsexpr->omit_quotes)
> jsexpr->use_json_coercion = true;
>
> case JSON_VALUE_OP:
> if (jsexpr-
drop domain if exists djs;
create domain djs as jsonb check ( value <> '"11"' );
SELECT JSON_QUERY(jsonb '"aaa"', '$.a' RETURNING djs keep quotes
DEFAULT '"11"' ON empty);
SELECT JSON_QUERY(jsonb '"aaa"', '$.a' RETURNING djs omit quotes
DEFAULT '"11"' ON empty);
SELECT JSON_QUERY(jsonb '"11"', '$'
On Tue, Jul 23, 2024 at 8:52 PM Amit Langote wrote:
>
> In the attached patch, I've also taken care of the problem mentioned
> in your latest email -- the solution I've chosen is not to produce the
> error when ERROR ON ERROR is specified but to use runtime coercion
> also for the jsonb type or an
On Tue, Jul 23, 2024 at 11:45 AM jian he wrote:
> On Mon, Jul 22, 2024 at 4:46 PM Amit Langote wrote:
> >
> > On Thu, Jul 18, 2024 at 3:04 PM jian he wrote:
> > > we still have problem in transformJsonBehavior
> > >
> > > currently transformJsonBehavior:
> > > SELECT JSON_VALUE(jsonb '1234', '$'
While reviewing the patch, I found some inconsistency on json_table EXISTS.
--tested based on your patch and master.
src4=# SELECT * FROM JSON_TABLE(jsonb '"a"', '$' COLUMNS (a jsonb
EXISTS PATH '$'));
ERROR: cannot cast behavior expression of type boolean to jsonb
src4=# SELECT * FROM JSON_TABLE
On Mon, Jul 22, 2024 at 4:46 PM Amit Langote wrote:
>
> On Thu, Jul 18, 2024 at 3:04 PM jian he wrote:
> > we still have problem in transformJsonBehavior
> >
> > currently transformJsonBehavior:
> > SELECT JSON_VALUE(jsonb '1234', '$' RETURNING bit(3) DEFAULT 010111 ON
> > ERROR);
> > ERROR: c
On Thu, Jul 18, 2024 at 3:04 PM jian he wrote:
> we still have problem in transformJsonBehavior
>
> currently transformJsonBehavior:
> SELECT JSON_VALUE(jsonb '1234', '$' RETURNING bit(3) DEFAULT 010111 ON
> ERROR);
> ERROR: cannot cast behavior expression of type text to bit
> LINE 1: ...VALUE
we still have problem in transformJsonBehavior
currently transformJsonBehavior:
SELECT JSON_VALUE(jsonb '1234', '$' RETURNING bit(3) DEFAULT 010111 ON ERROR);
ERROR: cannot cast behavior expression of type text to bit
LINE 1: ...VALUE(jsonb '1234', '$' RETURNING bit(3) DEFAULT 010111 ON ...
he
On Tue, Jul 2, 2024 at 5:03 PM Amit Langote wrote:
> On Tue, Jul 2, 2024 at 3:19 PM jian he wrote:
> > On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote:
> > >
> > > On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> > > > Alvaro Herrera writes:
> > > > >> +/*
> > > > >> + * For domains
On Tue, Jul 2, 2024 at 3:19 PM jian he wrote:
> On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote:
> >
> > On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > >> +/*
> > > >> + * For domains, consider the base type's typmod to decide whether
> > > >> to s
On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote:
>
> On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > >> +/*
> > >> + * For domains, consider the base type's typmod to decide whether
> > >> to setup
> > >> + * an implicit or explicit cast.
> > >> +
On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> Alvaro Herrera writes:
> >> +/*
> >> + * For domains, consider the base type's typmod to decide whether to
> >> setup
> >> + * an implicit or explicit cast.
> >> + */
> >> +if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
On Sun, Jun 30, 2024 at 2:24 AM Alvaro Herrera wrote:
>
> TBH I'm not super clear on why we decide on explicit or implicit cast
> based on presence of a typmod. Why isn't it better to always use an
> implicit one?
>
I am using an example to explain it.
SELECT JSON_SERIALIZE(JSON('{ "a" : 1 } '))
Alvaro Herrera writes:
>> +/*
>> + * For domains, consider the base type's typmod to decide whether to
>> setup
>> + * an implicit or explicit cast.
>> + */
>> +if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
>> +(void) getBaseTypeAndTypmod(returning->typid, &
> diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
> index 233b7b1cc9..df766cdec1 100644
> --- a/src/backend/parser/parse_expr.c
> +++ b/src/backend/parser/parse_expr.c
> @@ -3583,6 +3583,7 @@ coerceJsonFuncExpr(ParseState *pstate, Node *expr,
> Node *res;
On Fri, Jun 28, 2024 at 3:14 PM jian he wrote:
> On Thu, Jun 27, 2024 at 7:48 PM Amit Langote wrote:
> > >
> > > I've attempted that in the attached 0001, which removes
> > > JsonExpr.coercion_expr and a bunch of code around it.
> > >
> > > 0002 is now the original patch minus the changes to make
On Thu, Jun 27, 2024 at 7:48 PM Amit Langote wrote:
> >
> > I've attempted that in the attached 0001, which removes
> > JsonExpr.coercion_expr and a bunch of code around it.
> >
> > 0002 is now the original patch minus the changes to make
> > JSON_EXISTS(), JSON_QUERY(), and JSON_VALUE() behave as
On Thu, Jun 27, 2024 at 6:57 PM Amit Langote wrote:
> On Wed, Jun 26, 2024 at 11:46 PM jian he wrote:
> > On Wed, Jun 26, 2024 at 8:39 PM Amit Langote
> > wrote:
> > >
> > > >
> > > > The RETURNING variant giving an error is what the standard asks us to
> > > > do apparently. I read Tom's last
Hi,
On Wed, Jun 26, 2024 at 11:46 PM jian he wrote:
> On Wed, Jun 26, 2024 at 8:39 PM Amit Langote wrote:
> >
> > >
> > > The RETURNING variant giving an error is what the standard asks us to
> > > do apparently. I read Tom's last message on this thread as agreeing
> > > to that, even though he
hi.
I have assembled a list of simple examples, some works (for comparison
sake), most not work
as intended.
CREATE DOMAIN queryfuncs_char2 AS char(2) CHECK (VALUE NOT IN ('12'));
CREATE DOMAIN queryfuncs_d_interval AS interval(2) CHECK (VALUE is not null);
SELECT JSON_VALUE(jsonb '111', '$' RETU
On Wed, Jun 26, 2024 at 8:39 PM Amit Langote wrote:
>
> >
> > The RETURNING variant giving an error is what the standard asks us to
> > do apparently. I read Tom's last message on this thread as agreeing
> > to that, even though hesitantly. He can correct me if I got that
> > wrong.
> >
> > > yo
On Fri, Jun 21, 2024 at 10:48 PM Amit Langote wrote:
> On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> > hi.
> > i am a little confused.
> >
> > here[1] tom says:
> > > Yeah, I too think this is a cast, and truncation is the spec-defined
> > > behavior for casting to varchar with a specific leng
Hi,
Thanks for taking a look.
On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > > Peter Eisentraut writes:
> > > > > On 02.06.2
On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
>
> On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > On 02.06.24 21:46, Tom Lane wrote:
> > > >> If you don't
> > > >> like our current behavior, then
On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 02.06.24 21:46, Tom Lane wrote:
> > >> If you don't
> > >> like our current behavior, then either you have to say that RETURNING
> > >> with a length-limited
On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 02.06.24 21:46, Tom Lane wrote:
> >> If you don't
> >> like our current behavior, then either you have to say that RETURNING
> >> with a length-limited target type is illegal (which is problematic
> >> for the spec,
Peter Eisentraut writes:
> On 02.06.24 21:46, Tom Lane wrote:
>> If you don't
>> like our current behavior, then either you have to say that RETURNING
>> with a length-limited target type is illegal (which is problematic
>> for the spec, since they have no such type) or that the cast behaves
>> li
On 02.06.24 21:46, Tom Lane wrote:
If you don't
like our current behavior, then either you have to say that RETURNING
with a length-limited target type is illegal (which is problematic
for the spec, since they have no such type) or that the cast behaves
like an implicit cast, with errors for over
Peter Eisentraut writes:
> On 29.05.24 18:44, Tom Lane wrote:
>> Yeah, I too think this is a cast, and truncation is the spec-defined
>> behavior for casting to varchar with a specific length limit.
> The SQL standard says essentially that the output of json_serialize() is
> some string that whe
On 29.05.24 18:44, Tom Lane wrote:
Amit Langote writes:
On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera wrote:
On 2024-May-27, Alvaro Herrera wrote:
I just noticed this behavior, which looks like a bug to me:
select json_serialize('{"a":1, "a":2}' returning varchar(5));
json_serialize
───
Amit Langote writes:
> On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera
> wrote:
>> On 2024-May-27, Alvaro Herrera wrote:
>> I just noticed this behavior, which looks like a bug to me:
>>
>> select json_serialize('{"a":1, "a":2}' returning varchar(5));
>> json_serialize
>>
>> {"a
Hi Alvaro,
On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera wrote:
>
> On 2024-May-27, Alvaro Herrera wrote:
>
> > > JSON_SERIALIZE()
>
> I just noticed this behavior, which looks like a bug to me:
>
> select json_serialize('{"a":1, "a":2}' returning varchar(5));
> json_serialize
> ───
On Monday, May 27, 2024, Alvaro Herrera wrote:
> On 2024-May-27, Alvaro Herrera wrote:
>
> > > JSON_SERIALIZE()
>
> I just noticed this behavior, which looks like a bug to me:
>
> select json_serialize('{"a":1, "a":2}' returning varchar(5));
> json_serialize
>
> {"a":
>
> I thi
On 2024-May-27, Alvaro Herrera wrote:
> > JSON_SERIALIZE()
I just noticed this behavior, which looks like a bug to me:
select json_serialize('{"a":1, "a":2}' returning varchar(5));
json_serialize
{"a":
I think this function should throw an error if the destination type
doesn
47 matches
Mail list logo
