and few reverts!
Congratulations to both!
--
Thanks, Amit Langote
On Thu, Apr 18, 2024 at 9:33 AM Amit Langote wrote:
> On Mon, Apr 15, 2024 at 9:46 PM Amit Langote wrote:
> > On Sat, Apr 13, 2024 at 11:12 PM jian he
> > wrote:
> > > On Fri, Apr 12, 2024 at 5:44 PM Amit Langote
> > > wrote:
> > > >
> &
On Mon, Apr 15, 2024 at 9:46 PM Amit Langote wrote:
> On Sat, Apr 13, 2024 at 11:12 PM jian he wrote:
> > On Fri, Apr 12, 2024 at 5:44 PM Amit Langote
> > wrote:
> > >
> > > > elog(ERROR, "unrecognized json wrapper %d", wrapper);
> > > >
Hi,
On Sat, Apr 13, 2024 at 11:12 PM jian he wrote:
> On Fri, Apr 12, 2024 at 5:44 PM Amit Langote wrote:
> >
> > > elog(ERROR, "unrecognized json wrapper %d", wrapper);
> > > should be
> > > elog(ERROR, "unrecognized json wrapper %d", (i
On Thu, Apr 11, 2024 at 12:02 PM jian he wrote:
> On Wed, Apr 10, 2024 at 4:39 PM Amit Langote wrote:
> > Attached is a bit more polished version of that, which also addresses
> > the error messages in JsonPathQuery() and JsonPathValue(). I noticed
> > that there was
On Tue, Apr 9, 2024 at 8:37 PM Amit Langote wrote:
> On Tue, Apr 9, 2024 at 4:47 PM jian he wrote:
> > the last query error message is:
> > `
> > ERROR: no SQL/JSON item
> > `
> >
> > we are in ExecEvalJsonExprPath, can we output it to be:
> > `
>
SQL/JSON item found
> `
> in a json_table query, we can have multiple path_expressions, like the
> above query.
> it's not easy to know applying which path_expression failed.
Hmm, I'm not so sure about mentioning the details of the path because
path names are optional and printing path expression itself is not a
good idea. Perhaps, we could mention the column name which would
always be there, but we'd then need to add a new field column_name
that's optionally set to JsonFuncExpr and JsonExpr, that is, when they
are being set up for JSON_TABLE() columns. As shown in the attached.
With the patch you'll get:
ERROR: no SQL/JSON item found for column "b"
--
Thanks, Amit Langote
v1-0001-JSON_TABLE-mention-column-name-in-the-ON-EMPTY-er.patch
Description: Binary data
On Mon, Apr 8, 2024 at 2:02 PM jian he wrote:
> On Mon, Apr 8, 2024 at 11:21 AM jian he wrote:
> >
> > On Mon, Apr 8, 2024 at 12:34 AM jian he wrote:
> > >
> > > On Sun, Apr 7, 2024 at 9:36 PM Amit Langote
> > > wrote:
> > > > 0002 needs
gt;
> Hi Amit,
>
> this is a kind reminder that some feedback on your patch[0] is waiting for
> your reply.
> Thank you for your work!
Thanks for moving this to the next CF.
My apologies (especially to Robert) for not replying on this thread
for a long time.
I plan to start working on this soon.
--
Thanks, Amit Langote
tch to fix up get_json_expr_options() so that it now emits
WRAPPER and QUOTES such that they work correctly.
0002 needs an expanded commit message but I've run out of energy today.
--
Thanks, Amit Langote
v51-0001-Fix-JsonExpr-deparsing-to-emit-QUOTES-and-WRAPPE.patch
Description: Binary data
v51-0002-JSON_TABLE-Add-support-for-NESTED-columns.patch
Description: Binary data
Hi,
On Sat, Apr 6, 2024 at 3:55 PM jian he wrote:
> On Sat, Apr 6, 2024 at 2:03 PM Amit Langote wrote:
> >
> > >
> > > * problem with type "char". the view def output is not the same as
> > > the select * from v1.
> > >
>
On Sat, Apr 6, 2024 at 12:31 PM jian he wrote:
> On Fri, Apr 5, 2024 at 8:35 PM Amit Langote wrote:
> > Here's one. Main changes:
> >
> > * Fixed a bug in get_table_json_columns() which caused nested columns
> > to be deparsed incorrectly, something Jian reported
to -bugs:
https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org
I have moved the item to Older Bugs:
https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items#Live_issues
--
Thanks, Amit Langote
On Thu, Apr 4, 2024 at 9:02 PM Amit Langote wrote:
> I'll post the rebased 0002 tomorrow after addressing your comments.
Here's one. Main changes:
* Fixed a bug in get_table_json_columns() which caused nested columns
to be deparsed incorrectly, something Jian reported upthread.
* Simplif
On Fri, Apr 5, 2024 at 5:00 PM Alexander Lakhin wrote:
> 05.04.2024 10:09, Amit Langote wrote:
> > Seems like it might be a pre-existing issue, because I can also
> > reproduce the crash with:
>
> That's strange, because I get the error (on master, 6f132ed69).
>
Hi Alexander,
On Fri, Apr 5, 2024 at 3:00 PM Alexander Lakhin wrote:
>
> Hello Amit,
>
> 04.04.2024 15:02, Amit Langote wrote:
> > Pushed after fixing these and a few other issues. I didn't include
> > the testing function you proposed in your other email. It sound
JSON_TABLE()."),
> maybe change to something like:
> `
> errdetail("Only EMPTY or ERROR is allowed for ON ERROR in the
> top-level JSON_TABLE() ").
> `
> i guess mentioning "top-level" is fine.
> since "top-level", we have 19 appearances in functions-json.html.
Thanks for checking.
Pushed after fixing these and a few other issues. I didn't include
the testing function you proposed in your other email. It sounds
useful for testing locally but will need some work before we can
include it in the tree.
I'll post the rebased 0002 tomorrow after addressing your comments.
--
Thanks, Amit Langote
Hi Alvaro,
On Fri, Mar 29, 2024 at 2:04 AM Alvaro Herrera wrote:
> On 2024-Mar-28, Amit Langote wrote:
>
> > Here's patch 1 for the time being that implements barebones
> > JSON_TABLE(), that is, without NESTED paths/columns and PLAN clause.
> > I've tried to shape the
DEFAULT
> * nested json_table_column, with PLAN ( json_table_plan )
Yes, I think it will end up something like this. I'll try to post the
breakdown tomorrow.
--
Thanks, Amit Langote
On Mon, Mar 25, 2024 at 7:25 PM Richard Guo wrote:
> On Mon, Mar 25, 2024 at 5:17 PM Amit Langote wrote:
>> I've pushed this now.
>>
>> When updating the commit message, I realized that you had made the
>> right call to divide the the changes around not translating th
alized that you had made the
right call to divide the the changes around not translating the dummy
SpecialJoinInfos into a separate patch. So, I pushed it like that.
Thanks for working on this.
--
Thanks, Amit Langote
Hi Ashutosh,
On Tue, Mar 19, 2024 at 12:47 AM Ashutosh Bapat
wrote:
> On Mon, Mar 18, 2024 at 5:40 PM Amit Langote wrote:
>> >>
>> >> Sorry, I should’ve mentioned that I was interested in seeing cpu times to
>> >> compare the two approaches. Spe
Hi Horiguchi-san,
On Fri, Mar 22, 2024 at 9:51 AM Kyotaro Horiguchi
wrote:
> At Wed, 20 Mar 2024 21:53:52 +0900, Amit Langote
> wrote in
> > I'll push 0001 tomorrow.
>
> This patch (v44-0001-Add-SQL-JSON-query-functions.patch) introduced the
> follo
On Mon, Mar 18, 2024 at 8:57 PM Ashutosh Bapat
wrote:
> On Mon, Mar 18, 2024 at 5:05 PM Amit Langote wrote:
>> On Mon, Mar 18, 2024 at 20:11 Ashutosh Bapat
>> wrote:
>>> On Fri, Mar 15, 2024 at 11:45 AM Amit Langote
>>> wrote:
>>>> Could you plea
On Mon, Mar 18, 2024 at 20:11 Ashutosh Bapat
wrote:
> Hi Amit,
>
>
> On Fri, Mar 15, 2024 at 11:45 AM Amit Langote
> wrote:
>
>> > >
>> > > That being said I'm a big fan of using a local variable on stack and
>> > > filling it
{"type":"work", "number":"555-7252", "test":123}]}',
'$'
COLUMNS(
id numeric(2,2) PATH 'lax $.id',
last_name varCHAR(10) PATH 'lax $.name.last',
first_name VARCHAR(10) PATH 'lax $.name.first',
NESTED 'strict $.phones[-1]'COLUMNS (
"type" VARCHAR(10),
"number" VARCHAR(10)
)
) error on error
) as t;
ERROR: jsonpath array subscript is out of bounds
--
Thanks, Amit Langote
ode instead of the RTE, as follows:
-Assert(rte->rtekind == RTE_TABLEFUNC);
-objectname = "xmltable";
-objecttag = "Table Function Name";
+{
+TableFunc *tablefunc = ((TableFuncScan *) plan)->tablefunc;
+
+Assert(rte->rtekind == RTE_TABLEFUNC);
+switch (tablefunc->functype)
+{
+case TFT_XMLTABLE:
+objectname = "xmltable";
+break;
+case TFT_JSON_TABLE:
+objectname = "json_table";
+break;
+default:
+elog(ERROR, "invalid TableFunc type %d",
+ (int) tablefunc->functype);
+}
+objecttag = "Table Function Name";
+}
So that gets us what we need here.
Given that, 0002 does seem like an overkill and unnecessary, so I'll drop it.
> Please do add a test with EXPLAIN (FORMAT JSON) in 0003.
OK, will do.
--
Thanks, Amit Langote
[1]
https://www.postgresql.org/message-id/202401181711.qxjxpnl3ohnw%40alvherre.pgsql
itial message (with some minor fixes, adding MEMORY to explain etc).
> >
> > The results with the 20240130 patches are like this:
> >
> >tablesmasterpatched
> > -
> > 2 40.8 39.9
> > 3 151.7
--
t
(1 row)
Does that make sense?
In any case, JSON_EXISTS() added by the patch here returns whatever
the jsonpath executor returns. The latter is not touched by this
patch. PASSING args, which this patch adds, seem to be working
correctly too.
--
Thanks, Amit Langote
On Thu, Mar 7, 2024 at 23:14 Alvaro Herrera wrote:
> On 2024-Mar-07, Tomas Vondra wrote:
>
> > I was experimenting with the v42 patches, and I think the handling of ON
> > EMPTY / ON ERROR clauses may need some improvement.
>
> Well, the 2023 standard says things like
>
> ::=
> JSON_VALUE
>
On Thu, Mar 7, 2024 at 22:46 jian he wrote:
> On Thu, Mar 7, 2024 at 8:06 PM Amit Langote
> wrote:
> >
> >
> > Indeed.
> >
> > This boils down to the difference in the cast expression chosen to
> > convert the source value to int in the two cases.
&
o suppress the error and return NULL, so the
correct behavior is when the source value has quotes.
I think we'll need either:
* fix the code in 0001 to avoid getting numeric_int4() in this case,
and generally cast functions that don't have soft-error handling
support, in favor of using IO coercion.
* fix FuncExpr (like CoerceViaIO) to respect SQL/JSON's request to
suppress errors and fix downstream functions like numeric_int4() to
comply by handling errors softly.
I'm inclined to go with the 1st option as we already have the
infrastructure in place -- input functions can all handle errors
softly.
For the latter, it uses numeric_int4() which doesn't support
soft-error handling, so throws the error. With quotes, the
--
Thanks, Amit Langote
--
Thanks, Amit Langote
used
> printtup: 8192 total in 1 blocks; 7952 free (0 chunks); ...
> ...
> ...
> Grand total: 2544132336 bytes in 528 blocks; 7484504 free
> (1340 chunks); 2536647832 used
> --
>
> I'd say 2.5GB in ExecutorState seems a bit excessive ... Seems there's
> some memory management issue? My guess is we're not releasing memory
> allocated while parsing the JSON or building JSON output.
>
> I'm not attaching the data, but I can provide that if needed - it's
> about 600MB compressed. The structure is not particularly complex, it's
> movie info from [1] combined into a JSON document (one per movie).
Thanks for the report.
Yeah, I'd like to see the data to try to drill down into what's piling
up in ExecutorState. I want to be sure of if the 1st, query functions
patch, is not implicated in this, because I'd like to get that one out
of the way sooner than later.
--
Thanks, Amit Langote
e it broke, but I do see that the query
> > successfully does nothing in v15.)
>
> You're right, this is the commit that broke it. It's unclear to me if
> Amit is available to look at it, so I'll give this a look tomorrow if he
> isn't.
I'll look at this today.
--
Thanks, Amit Langote
On Fri, Jan 26, 2024 at 0:15 Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
> >> -1 please. We should not break that abstraction for the sake
> >> of ignorable warnings on ancient compilers.
>
> > Ignoring the war
On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
> Amit Langote writes:
> > On Thu, Jan 25, 2024 at 2:59 PM Richard Guo
> wrote:
> >> I came across a warning when building master (a044e61f1b) on old GCC
> >> (4.8.5).
>
> > Will apply the attached, which d
On Thu, Jan 25, 2024 at 6:09 PM Amit Langote wrote:
> On Wed, Jan 24, 2024 at 10:11 PM Amit Langote wrote:
> > I still need to take a look at your other report regarding typmod but
> > I'm out of energy today.
>
> The attached updated patch should address one of the con
On Thu, Jan 25, 2024 at 4:47 PM Richard Guo wrote:
> On Thu, Jan 25, 2024 at 2:28 PM Amit Langote wrote:
>>
>> On Thu, Jan 25, 2024 at 2:59 PM Richard Guo wrote:
>> > I came across a warning when building master (a044e61f1b) on old GCC
>> > (4.8.5).
&
ll apply the attached, which does this:
- return BoolGetDatum(!SOFT_ERROR_OCCURRED());
+ return BoolGetDatum(!escontext.error_occurred);
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
0001-Silence-compiler-warning-introduced-in-1edb3b491b.patch
Description: Binary data
> "objectname" to be reported here. I admit it's perhaps redundant. In
> this case we'd just remove lines 3896-3899 shown above and let it be
> NULL.
Showing the function's name spelled out in the query (XMLTABLE /
JSON_TABLE) seems fine to me, even though maybe a bit redundant, yes.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
after a bit of polishing, so if anyone would
like to take a look, please let me know. I'll post a new set
tomorrow.
0007, the query functions patch, also looks close to ready, though I
might need to change a few things in it as I work through the
JSON_TABLE() changes.
--
Thanks, Amit Langote
EDB
turnType(jsexpr);
> + ret->typmod = -1;
> + }
> + jsexpr->result_coercion = coerceJsonFuncExprOutput(pstate, jsexpr);
>
> I noticed, if (!OidIsValid(jsexpr->returning->typid)) is the true
> function JsonFuncExprDefaultReturnType may be called twice, not sure
> if it'
On Sat, Dec 9, 2023 at 2:05 AM Andrew Dunstan wrote:
> On 2023-12-08 Fr 11:37, Robert Haas wrote:
> > On Fri, Dec 8, 2023 at 1:59 AM Amit Langote wrote:
> >> Would it be messy to replace the lookahead approach by whatever's
> >> suiable *in the future* when it
can bump up
> against PATH without wanting that to turn into NESTED_LA PATH, then I
> think it's likely that this whole approach will unravel. As long as we
> don't think that will ever happen, I think it's probably OK. If we do
> think it's going to happen, then we should probably grit ou
gt; By the way, in the above "{ $$ = list_make2($1, $4); }" what does $4
> refer to? (I don't know gram.y)
$1 and $4 refer to the 1st and 4th symbols in the following:
json_behavior ON EMPTY_P json_behavior ON ERROR_P
So $1 gives the json_behavior (JsonBehavior) nod
ened there.)
The following commit sounds like it might be related?
commit 06a7c3154f5bfad65549810cc84f0e3a77b408bf
Author: Tom Lane
Date: Fri Sep 18 16:46:26 2020 -0400
Allow most keywords to be used as column labels without requiring AS.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Thu, Nov 23, 2023 at 4:38 AM Andres Freund wrote:
> On 2023-11-21 12:52:35 +0900, Amit Langote wrote:
> > version gram.o text bytes %change gram.c bytes %change
> >
> > 9.6 534010 -2108984 -
> > 10 582554
On Wed, Nov 22, 2023 at 3:09 PM Amit Langote wrote:
> The last line in the chart I sent in the last email now look like this:
>
> 17-sqljson 670262 2.57 2640912 1.34
>
> meaning the gram.o text size changes by 2.57% as opposed to 2.97%
> before your fixes.
On Fri, Nov 17, 2023 at 6:40 PM Alvaro Herrera wrote:
> On 2023-Nov-17, Amit Langote wrote:
>
> > On Fri, Nov 17, 2023 at 4:27 PM jian he wrote:
>
> > > some enum declaration, ending element need an extra comma?
> >
> > Didn't know about the conventi
On Wed, Nov 22, 2023 at 4:37 PM Andres Freund wrote:
> On 2023-11-22 15:09:36 +0900, Amit Langote wrote:
> > OK, I will keep polishing 0001-0003 with the intent to push it next
> > week barring objections / damning findings.
>
> I don't think the patchset is quite there
On Nov 16, 2023, at 17:48, Amit Langote wrote:
> On Thu, Nov 16, 2023 at 2:11 AM Andres Freund wrote:
>> On 2023-11-15 22:00:41 +0900, Amit Langote wrote:
>>>> This causes a nontrivial increase in the size of the parser (~5% in an
>>>> optimized build he
the RETURNING
> + * type. Also see the description of possible step addresses this
> + * could be set to in the definition of JsonExprState.ZZ
> + */
>
> "ZZ", typo?
Indeed.
Will include the fixes in the next version.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Thu, Nov 16, 2023 at 2:11 AM Andres Freund wrote:
> On 2023-11-15 22:00:41 +0900, Amit Langote wrote:
> > > This causes a nontrivial increase in the size of the parser (~5% in an
> > > optimized build here), I wonder if we can do better.
> >
> > Hmm, sorry if
Hi Erik,
On Thu, Nov 16, 2023 at 13:52 Erik Rijkers wrote:
> Op 11/15/23 om 14:00 schreef Amit Langote:
> > Hi,
>
> [..]
>
> > Attached updated patch. The version of 0001 that I posted on Oct 11
> > to add the error-safe version of CoerceViaIO contained many
>
Hi Erik,
On Sat, Nov 11, 2023 at 11:52 Erik Rijkers wrote:
> Hi,
>
> At the moment, what is the patchset to be tested? The latest SQL/JSON
> server I have is from September, and it's become unclear to me what
> belongs to the SQL/JSON patchset. It seems to me cfbot erroneously
> shows green
as error-safe
input handling, possibly as a separate patch. IOW, the SQL/JSON patch
shouldn't really make a list of types to report as unsupported.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
at do you think of these options?
Yes maybe, though I'd first like to have a good answer to why is that
logic necessary at all. Maybe you think it's better to emit an error
in the SQL/JSON layer of code than in the type input function if it's
unsafe?
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Tue, Oct 24, 2023 at 9:51 Jeff Davis wrote:
> On Wed, 2023-10-18 at 22:34 +1300, David Rowley wrote:
> > It would be good to learn how many of the committers out of the ones
> > you listed that --enable-indent-checks would have saved from breaking
> > koel.
>
> I'd find that a useful option.
g_proc
(prosafe) or pg_type (typinsafe), but apparently there isn't.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
Hi Anton,
On Tue, Oct 17, 2023 at 4:11 PM Anton A. Melnikov
wrote:
> On 17.10.2023 07:02, Amit Langote wrote:
>
> > One thing jian he missed during the debugging is that
> > ExecEvalJsonExprCoersion() receives the EMPTY ARRAY value via
> > *op->resvalue/resnull, set
at
ExecEvalJsonExprCoersion() receives the EMPTY ARRAY value via
*op->resvalue/resnull, set by ExecEvalJsonExprBehavior(), because
that's the ON EMPTY behavior specified in the constraint. The bug was
that the code in ExecEvalJsonExprCoercion() failed to set val_string
to that value ("[]") before passing to InputFunctionCallSafe(), so the
latter would assume the input is NULL.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
> Time: 6.858 ms
> @!>
>
> We're currently looking into this case.
Thanks for the report. I think I've figured out the problem --
ExecEvalJsonExprCoercion() mishandles the EMPTY ARRAY ON EMPTY case.
I'm reading the other 2 patches...
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Wed, Oct 11, 2023 at 2:08 PM Amit Langote wrote:
> On Sat, Oct 7, 2023 at 6:49 AM Andres Freund wrote:
> > On 2023-09-29 13:57:46 +0900, Amit Langote wrote:
> > > Thanks. I will push the attached 0001 shortly.
> >
> > Sorry for not looking at this earl
Hi Andres,
On Sat, Oct 7, 2023 at 6:49 AM Andres Freund wrote:
> Hi,
>
> On 2023-09-29 13:57:46 +0900, Amit Langote wrote:
> > Thanks. I will push the attached 0001 shortly.
>
> Sorry for not looking at this earlier.
Thanks for the review. Replying here only to your comm
On Fri, Oct 6, 2023 at 19:01 Alvaro Herrera wrote:
> On 2023-Oct-06, Amit Langote wrote:
>
> > 2. Assignment of op->d.iocoerce.escontext needed to be changed like this:
> >
> > v_params[4] =
> l_ptr_const(op->d.iocoerce.escontext,
>
On Wed, Oct 4, 2023 at 10:26 PM Amit Langote wrote:
> On Tue, Oct 3, 2023 at 10:11 PM Amit Langote wrote:
> > On Mon, Oct 2, 2023 at 2:26 PM Amit Langote wrote:
> > > On Mon, Oct 2, 2023 at 1:24 PM Amit Langote
> > > wrote:
> > > > Pushed this 30 min ag
On Tue, Oct 3, 2023 at 10:11 PM Amit Langote wrote:
> On Mon, Oct 2, 2023 at 2:26 PM Amit Langote wrote:
> > On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote:
> > > Pushed this 30 min ago (no email on -committers yet!) and am looking
> > > at the following llvm
On Mon, Oct 2, 2023 at 2:26 PM Amit Langote wrote:
> On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote:
> > Pushed this 30 min ago (no email on -committers yet!) and am looking
> > at the following llvm crash reported by buildfarm animal pogona [1]:
> >
>
On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote:
> Pushed this 30 min ago (no email on -committers yet!) and am looking
> at the following llvm crash reported by buildfarm animal pogona [1]:
>
> #4 0x7f5bceb673d5 in __assert_fail_base (fmt=0x7f5bcecdbdc8
> "%s%s%s:%
On Fri, Sep 29, 2023 at 1:57 PM Amit Langote wrote:
> On Thu, Sep 28, 2023 at 8:04 PM Alvaro Herrera
> wrote:
> > On 2023-Sep-27, Amit Langote wrote:
> > > Maybe the following is better:
> > >
> > > + /*
> > > +* For expression nodes that su
On Wed, Sep 27, 2023 at 8:07 PM Ashutosh Bapat
wrote:
> On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote:
> > + /*
> > +* But the list of operator OIDs and the list of expressions may be
> > +* referenced somewhere else. Do not free those.
> >
On Wed, Sep 27, 2023 at 8:07 PM Ashutosh Bapat
wrote:
> On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote:
> > Just out of curiosity, is their not being present in join_info_list
> > problematic in some manner, such as missed optimization opportunities
> > for ch
Hi Ashutosh,
On Thu, Sep 21, 2023 at 1:20 PM Ashutosh Bapat
wrote:
> On Thu, Sep 21, 2023 at 6:37 AM Amit Langote wrote:
> > On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat
> > wrote:
> > > On Wed, Sep 20, 2023 at 5:24 PM Amit Langote
> > > wrote:
On Wed, Sep 6, 2023 at 11:20 PM Robert Haas wrote:
> On Wed, Sep 6, 2023 at 5:12 AM Amit Langote wrote:
> > Attached updated patches. Thanks for the review.
>
> I think 0001 looks ready to commit. I'm not sure that the commit
> message needs to mention future patches her
On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat
wrote:
> On Wed, Sep 20, 2023 at 5:24 PM Amit Langote wrote:
> > Just one comment on 0003:
> >
> > + /*
> > +* Dummy SpecialJoinInfos do not have any translated fields and hence
> >
is instead be Assert(child_sjinfo->jointype != JOIN_INNER)?
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Tue, Sep 19, 2023 at 9:00 PM Amit Langote wrote:
> On Tue, Sep 19, 2023 at 7:37 PM jian he wrote:
> > ---
> > https://www.postgresql.org/docs/current/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC
> > >> When the return value of a function is dec
NULL. Maybe we can validate it in
> transformJsonFuncExpr?
> ---
I'm not sure whether we should make the parser complain about the
weird types being specified in RETURNING. The NULL you get in the
above example is because of the following error:
select json_qu
Hi Erik,
On Mon, Sep 18, 2023 at 19:09 Erik Rijkers wrote:
> Op 9/18/23 om 05:15 schreef Amit Langote:
> > On Sun, Sep 17, 2023 at 3:34 PM Erik Rijkers wrote:
> >> Op 9/14/23 om 10:14 schreef Amit Langote:
> >>>
> >>>
> >>
> >> Hi
> > Anyone remember why this is here? Should we remove it?
> >
> >
> > +1 for removing, on the basis that it is not suprising, and would
> > pollute logs for most configurations.
>
> done
+1 and thanks. May have been there as a debugging aid if anything.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
t; line should be ON EMPTY ?
Correct too.
> Other than that, the doc looks good.
Thanks for the review.
I will post a new version after finishing working on a few other
improvements I am working on.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Fri, Aug 11, 2023 at 14:31 Amit Langote wrote:
> On Wed, Aug 9, 2023 at 1:05 AM Robert Haas wrote:
> > On Tue, Aug 8, 2023 at 10:32 AM Amit Langote
> wrote:
> > > But should ExecInitNode() subroutines return the partially initialized
> > > PlanState node or
On Wed, Aug 9, 2023 at 9:48 PM Robert Haas wrote:
> On Wed, Aug 9, 2023 at 6:22 AM Amit Langote wrote:
> > > > I'm assuming it's not
> > > > too ugly if ExecInitAppend() uses IsParallelWorker() to decide whether
> > > > it should be writing to EStat
On Tue, Aug 8, 2023 at 11:16 PM Robert Haas wrote:
> On Tue, Aug 8, 2023 at 2:58 AM Amit Langote wrote:
> > Or we could consider something like the patch I mentioned in my 1st
> > email. The idea there was to pass the pruning result via a separate
> > channel, not
On Tue, Aug 8, 2023 at 12:36 AM Robert Haas wrote:
> On Thu, Aug 3, 2023 at 4:37 AM Amit Langote wrote:
> > Here's a patch set where the refactoring to move the ExecutorStart()
> > calls to be closer to GetCachedPlan() (for the call sites that use a
> > CachedPlan) is extr
On Tue, Aug 8, 2023 at 12:53 AM Robert Haas wrote:
> On Mon, Aug 7, 2023 at 10:25 AM Amit Langote wrote:
> > Note we’re talking here about “initial” pruning that occurs during
> > ExecInitNode(). Workers are only launched during ExecGather[Merge]() which
> > there
during
ExecInitNode(). Workers are only launched during ExecGather[Merge]() which
thereafter do ExecInitNode() on their copy of the the plan tree. So if we
are to pass the pruning results for cross-checking, it will have to be from
the leader to workers.
> --
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
Hi,
On Fri, Aug 4, 2023 at 19:01 Erik Rijkers wrote:
> Op 7/21/23 om 12:33 schreef Amit Langote:
> >
> > Thanks for taking a look.
> >
>
> Hi Amit,
>
> Is there any chance to rebase the outstanding SQL/JSON patches, (esp.
> json_query)?
Yes, wor
time do not have tuples in the
> pg_proc catalog. Is it unnecessary?
Yes. These are not functions that get pg_proc entries, but SQL
constructs that *look like* functions, similar to XMLEXISTS(), etc.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
estate(pstate);
>
> return resultRelInfo;
> }
>
> In this case, how can we get the relinfo->ri_RootResultRelInfo to store the
> appropriate data?
Your function doesn't seem to have access to the ModifyTableState
node, so setting ri_RootResultRelInfo to the correct ResultRelInfo
node does not seem doable.
As I suggested in my previous reply, please check if passing 0 (not
list_length(estate->es_range_table)) for the 3rd argument
InitResultRelInfo() fixes the problem and gives the correct result.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Fri, Jul 21, 2023 at 7:33 PM Amit Langote wrote:
> On Fri, Jul 21, 2023 at 1:02 AM Alvaro Herrera
> wrote:
> > On 2023-Jul-21, Amit Langote wrote:
> >
> > > I’m thinking of pushing 0001 and 0002 tomorrow barring objections.
> >
> > 0001 looks reaso
ate->opts.force_quote_all)
{
int i;
for (i = 0; i < num_phys_attrs; i++)
cstate->opts.force_quote_flags[i] = true;
}
Perhaps we could fix the inconsistency by changing the force_quote_all
code to use MemSet() too. I'll defer whether to do that to Andrew's
judgement.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Thu, Jul 20, 2023 at 17:19 Amit Langote wrote:
> On Wed, Jul 19, 2023 at 5:17 PM Amit Langote
> wrote:
> > On Wed, Jul 19, 2023 at 12:53 AM Alvaro Herrera
> wrote:
> > > On 2023-Jul-18, Amit Langote wrote:
> > >
> > > > Attached upd
Hello,
On Thu, Jul 20, 2023 at 10:35 AM jian he wrote:
> On Tue, Jul 18, 2023 at 5:11 PM Amit Langote wrote:
> > > Op 7/17/23 om 07:00 schreef jian he:
> > > > hi.
> > > > seems there is no explanation about, json_api_common_syntax in
> > > &g
On Wed, Jul 19, 2023 at 5:17 PM Amit Langote wrote:
> On Wed, Jul 19, 2023 at 12:53 AM Alvaro Herrera
> wrote:
> > On 2023-Jul-18, Amit Langote wrote:
> > > b6e1157e7d Don't include CaseTestExpr in JsonValueExpr.formatted_expr
> >
> > I feel a bit uneasy ab
On Wed, Jul 19, 2023 at 12:53 AM Alvaro Herrera wrote:
> On 2023-Jul-18, Amit Langote wrote:
>
> > Attached updated patches. In 0002, I removed the mention of the
> > RETURNING clause in the JSON(), JSON_SCALAR() documentation, which I
> > had forgotten to do in the la
ResultRelInfo pointing at the wrong RTE via its ri_RangeTableIndex.
That code should perhaps set the ri_RangeTableIndex to 0 if it doesn't
know the actual existing RTE corresponding to that result relation.
If you set it to some non-0 value, the RTE that it points to should
satisfy invariants such as having the corresponding RTEPermissionInfo
present in the rteperminfos list if necessary.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
() most likely via
markRTEForSelectPriv()) is not expecting to be called with? I would
be helpful to see a backtrace when the error occurs to be sure.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On Mon, Jul 10, 2023 at 5:27 PM Daniel Gustafsson wrote:
> > On 21 Mar 2023, at 06:03, Amit Langote wrote:
> > On Tue, Mar 21, 2023 at 3:54 AM Gregory Stark (as CFM)
> > wrote:
> >> On Mon, 17 Oct 2022 at 14:59, Robert Haas wrote:
>
> >>> But I t
On Fri, Jul 7, 2023 at 8:31 PM Peter Eisentraut wrote:
> On 21.06.23 10:25, Amit Langote wrote:
> > I realized that the patch for the "other sql/json functions" part is
> > relatively straightforward and has no dependence on the "sql/json
> > query function
1 - 100 of 2267 matches
Mail list logo
