Andrew Dunstan writes:
> I suggest just submitting the Input function stuff on its own, I think
> that means not patches 3,4,15 at this stage. Maybe we would also need a
> small test module to call the functions, or at least some of them.
> The earlier we can get this in the earlier SQL/JSON patch
On 2022-09-01 Th 09:54, Nikita Glukhov wrote:
>
> On 31.08.2022 23:39, Nikita Glukhov wrote:
>
>> And here is a quick POC patch with an example for COPY and float4
> I decided to go further and use new API in SQL/JSON functions
> (even if it does not make real sense now).
>
> I have added functi
On Fri, Sep 2, 2022 at 8:56 PM Justin Pryzby wrote:
> On Wed, Aug 31, 2022 at 03:51:18PM +0900, Amit Langote wrote:
> > Finally, I get this warning:
> >
> > execExprInterp.c: In function ‘ExecJsonCoerceCStringToText’:
> > execExprInterp.c:4765:3: warning: missing braces around initializer
> > [-Wm
On Wed, Aug 31, 2022 at 03:51:18PM +0900, Amit Langote wrote:
> Finally, I get this warning:
>
> execExprInterp.c: In function ‘ExecJsonCoerceCStringToText’:
> execExprInterp.c:4765:3: warning: missing braces around initializer
> [-Wmissing-braces]
>NameData encoding = {0};
>^
> execExprIn
On 9/1/22 5:13 PM, Andrew Dunstan wrote:
On 2022-08-31 We 14:22, Andrew Dunstan wrote:
On 2022-08-31 We 12:48, Jonathan S. Katz wrote:
With RMT hat on -- Andrew can you please revert the patchset?
:-(
Yes, I'll do it, starting with the v15 branch. Might take a day or so.
done
Thank
On 2022-08-31 We 14:22, Andrew Dunstan wrote:
> On 2022-08-31 We 12:48, Jonathan S. Katz wrote:
>>
>> With RMT hat on -- Andrew can you please revert the patchset?
>
> :-(
>
>
> Yes, I'll do it, starting with the v15 branch. Might take a day or so.
>
>
done
cheers
andrew
--
Andrew Dunstan
On 31.08.2022 23:39, Nikita Glukhov wrote:
And here is a quick POC patch with an example for COPY and float4
I decided to go further and use new API in SQL/JSON functions
(even if it does not make real sense now).
I have added function for checking expressions trees, special
executor steps fo
On 31.08.2022 20:14, Tom Lane wrote:
Robert Haas writes:
On Wed, Aug 31, 2022 at 1:06 PM Tom Lane wrote:
The currently proposed patchset hacks up a relatively small number
of core datatypes to be able to do that. But it's just a hack
and there's no prospect of extension types being able to
On 8/31/22 3:08 PM, Andrew Dunstan wrote:
On 2022-08-31 We 14:45, Tom Lane wrote:
To the extent that there was a management failure here, it was that
we didn't press for a resolution sooner. Given the scale of the
concerns raised in June, I kind of agree with Andres' opinion that
fixing them p
On 2022-08-31 We 14:45, Tom Lane wrote:
> To the extent that there was a management failure here, it was that
> we didn't press for a resolution sooner. Given the scale of the
> concerns raised in June, I kind of agree with Andres' opinion that
> fixing them post-freeze was doomed to failure. I
Bruce Momjian writes:
> I guess you are saying that setting a cut-off was a bad idea, or that
> the cut-off was too close to the final release date. For me, I think
> there were three questions:
> 1. Were subtransactions acceptable, consensus no
> 2. Could trapping errors work for PG 15, conse
On Wed, Aug 31, 2022 at 12:04:44PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > From my POV the only real discussion is whether we'd want to revert this in
> > 15
> > and HEAD or just 15. There's imo a decent point to be made to just revert in
> > 15 and aggressively press forward with the
On Wed, Aug 31, 2022 at 12:26:29PM -0400, Robert Haas wrote:
> someone else to make the decision. But that's not how it works. The
> RMT concept was invented precisely to solve problems like this one,
> where the patch authors don't really want to revert it but other
> people think it's pretty bust
On 2022-08-31 We 12:48, Jonathan S. Katz wrote:
>
>
> With RMT hat on -- Andrew can you please revert the patchset?
:-(
Yes, I'll do it, starting with the v15 branch. Might take a day or so.
cheers (kinda)
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Robert Haas writes:
> On Wed, Aug 31, 2022 at 1:06 PM Tom Lane wrote:
>> (I don't say that we'd convert every datatype to do so right away;
>> in the long run we should, but I'm content to start with just the
>> same core types touched here.)
> I would be in favor of making more of an effort tha
On Wed, Aug 31, 2022 at 1:06 PM Tom Lane wrote:
> The currently proposed patchset hacks up a relatively small number
> of core datatypes to be able to do that. But it's just a hack
> and there's no prospect of extension types being able to join
> in the fun. I think where we need to start, for v
I wrote:
> Andres Freund writes:
>> From my POV the only real discussion is whether we'd want to revert this in
>> 15
>> and HEAD or just 15. There's imo a decent point to be made to just revert in
>> 15 and aggressively press forward with the changes posted in this thread.
> I'm not for that.
On 8/31/22 12:26 PM, Robert Haas wrote:
On Wed, Aug 31, 2022 at 10:20 AM Jonathan S. Katz wrote:
Andres, Robert, Tom: With this recent work, have any of your opinions
changed on including SQL/JSON in v15?
No. Nothing's been committed, and there's no time to review anything
in detail, and ther
Hi,
On 2022-08-31 12:26:29 -0400, Robert Haas wrote:
> On Wed, Aug 31, 2022 at 10:20 AM Jonathan S. Katz
> wrote:
> > Andres, Robert, Tom: With this recent work, have any of your opinions
> > changed on including SQL/JSON in v15?
>
> No. Nothing's been committed, and there's no time to review a
On Wed, Aug 31, 2022 at 10:20 AM Jonathan S. Katz wrote:
> Andres, Robert, Tom: With this recent work, have any of your opinions
> changed on including SQL/JSON in v15?
No. Nothing's been committed, and there's no time to review anything
in detail, and there was never going to be. Nikita said he
Andres Freund writes:
> On 2022-08-31 10:20:24 -0400, Jonathan S. Katz wrote:
>> Andres, Robert, Tom: With this recent work, have any of your opinions
>> changed on including SQL/JSON in v15?
> I don't really know what to do here. It feels blatantly obvious that this code
> isn't even remotely cl
On 2022-08-30 Tu 17:25, Nikita Glukhov wrote:
>
>
>
Patches 0001-0006:
Yeah, these add the overhead of an extra function call (typin() ->
typin_opt_error()) in possibly very common paths. Other than
refactoring *all* places that call typin() to use the new API, the
Hi,
On 2022-08-31 10:20:24 -0400, Jonathan S. Katz wrote:
> Andres, Robert, Tom: With this recent work, have any of your opinions
> changed on including SQL/JSON in v15?
I don't really know what to do here. It feels blatantly obvious that this code
isn't even remotely close to being releasable. I
On 8/31/22 8:38 AM, Andrew Dunstan wrote:
On 2022-08-31 We 07:01, Amit Langote wrote:
On Wed, Aug 31, 2022 at 3:51 PM Amit Langote wrote:
SELECT JSON_VALUE(jsonb '"aaa"', '$' RETURNING int DEFAULT 111 ON ERROR);
- json_value
-
-111
-(1 row)
-
+ERROR: syntax error at or
On 2022-08-31 We 07:01, Amit Langote wrote:
> On Wed, Aug 31, 2022 at 3:51 PM Amit Langote wrote:
>> SELECT JSON_VALUE(jsonb '"aaa"', '$' RETURNING int DEFAULT 111 ON ERROR);
>> - json_value
>> -
>> -111
>> -(1 row)
>> -
>> +ERROR: syntax error at or near "DEFAULT"
>> +LINE
On Wed, Aug 31, 2022 at 3:51 PM Amit Langote wrote:
> SELECT JSON_VALUE(jsonb '"aaa"', '$' RETURNING int DEFAULT 111 ON ERROR);
> - json_value
> -
> -111
> -(1 row)
> -
> +ERROR: syntax error at or near "DEFAULT"
> +LINE 1: ...ELECT JSON_VALUE(jsonb '"aaa"', '$' RETURNING int
On Wed, Aug 31, 2022 at 3:51 PM Amit Langote wrote:
> On Wed, Aug 31, 2022 at 6:25 AM Nikita Glukhov
> wrote:
> > v10 patches
>
> Finally, I get this warning:
>
> execExprInterp.c: In function ‘ExecJsonCoerceCStringToText’:
> execExprInterp.c:4765:3: warning: missing braces around initializer
>
On Wed, Aug 31, 2022 at 6:25 AM Nikita Glukhov wrote:
> On 30.08.2022 11:09, Amit Langote wrote:
> First of all, regarding 0009, my understanding was that we should
> disallow DEFAULT expression ON ERROR too for now, so something like
> the following does not occur:
>
> SELECT JSON_VALUE(jsonb '"e
On 8/30/22 9:16 AM, Andrew Dunstan wrote:
On 2022-08-30 Tu 06:29, Amit Langote wrote:
On Tue, Aug 30, 2022 at 6:19 PM Alvaro Herrera wrote:
On 2022-Aug-30, Amit Langote wrote:
Patches 0001-0006:
Yeah, these add the overhead of an extra function call (typin() ->
typin_opt_error()) in possib
On 2022-08-30 Tu 06:29, Amit Langote wrote:
> On Tue, Aug 30, 2022 at 6:19 PM Alvaro Herrera
> wrote:
>> On 2022-Aug-30, Amit Langote wrote:
>>
>>> Patches 0001-0006:
>>>
>>> Yeah, these add the overhead of an extra function call (typin() ->
>>> typin_opt_error()) in possibly very common paths.
On Tue, Aug 30, 2022 at 6:19 PM Alvaro Herrera wrote:
> On 2022-Aug-30, Amit Langote wrote:
>
> > Patches 0001-0006:
> >
> > Yeah, these add the overhead of an extra function call (typin() ->
> > typin_opt_error()) in possibly very common paths. Other than
> > refactoring *all* places that call t
On 2022-Aug-30, Amit Langote wrote:
> Patches 0001-0006:
>
> Yeah, these add the overhead of an extra function call (typin() ->
> typin_opt_error()) in possibly very common paths. Other than
> refactoring *all* places that call typin() to use the new API, the
> only other option seems to be to l
On Tue, Aug 30, 2022 at 6:49 AM Nikita Glukhov wrote:
> On 29.08.2022 15:56, Amit Langote wrote:
> On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov
> wrote:
> I have completed in v9 all the things I previously planned:
>
> BTW, maybe the following hunk in boolin_opt_error() is unnecessary?
>
> -
On 2022-08-29 Mo 09:35, Jonathan S. Katz wrote:
> On 8/29/22 8:56 AM, Amit Langote wrote:
>> On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov
>> wrote:
>
>> I am not sure if it's OK to eval_const_expressions() on a Query
>> sub-expression during parse-analysis. IIUC, it is only correct to
>> appl
On 8/29/22 8:56 AM, Amit Langote wrote:
On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov wrote:
I am not sure if it's OK to eval_const_expressions() on a Query
sub-expression during parse-analysis. IIUC, it is only correct to
apply it to after the rewriting phase.
Maybe it would be bette
On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov wrote:
> On 26.08.2022 22:25, Andrew Dunstan wrote:
>
> On 2022-08-24 We 20:05, Nikita Glukhov wrote:
>
> v8 - is a highly WIP patch, which I failed to finish today.
> Even some test cases fail now, and they simply show unfinished
> things like casts
On 8/26/22 4:36 PM, Andrew Dunstan wrote:
On 2022-08-26 Fr 16:11, Nikita Glukhov wrote:
Hi,
On 26.08.2022 22:25, Andrew Dunstan wrote:
On 2022-08-24 We 20:05, Nikita Glukhov wrote:
v8 - is a highly WIP patch, which I failed to finish today.
Even some test cases fail now, and they simply sho
On 2022-08-26 Fr 16:11, Nikita Glukhov wrote:
>
> Hi,
>
> On 26.08.2022 22:25, Andrew Dunstan wrote:
>> On 2022-08-24 We 20:05, Nikita Glukhov wrote:
>>> v8 - is a highly WIP patch, which I failed to finish today.
>>> Even some test cases fail now, and they simply show unfinished
>>> things like
On 2022-08-26 Fr 12:36, Jonathan S. Katz wrote:
> On 8/24/22 8:16 PM, Andrew Dunstan wrote:
>>
>> On 2022-08-24 We 20:05, Nikita Glukhov wrote:
>>>
>>>
>>> v8 - is a highly WIP patch, which I failed to finish today.
>>> Even some test cases fail now, and they simply show unfinished
>>> things lik
On 8/24/22 8:16 PM, Andrew Dunstan wrote:
On 2022-08-24 We 20:05, Nikita Glukhov wrote:
v8 - is a highly WIP patch, which I failed to finish today.
Even some test cases fail now, and they simply show unfinished
things like casts to bytea (they can be simply removed) and missing
safe input fun
On 2022-08-24 We 20:05, Nikita Glukhov wrote:
>
>
> v8 - is a highly WIP patch, which I failed to finish today.
> Even some test cases fail now, and they simply show unfinished
> things like casts to bytea (they can be simply removed) and missing
> safe input functions.
>
Thanks for your work, p
On Wed, Aug 24, 2022 at 11:55 AM Amit Langote wrote:
> On Wed, Aug 24, 2022 at 6:29 AM Nikita Glukhov
> wrote:
> > Here is my plan:
> >
> > 0. Take my last v7-0001 patch as a base. It already contains refactoring
> > of JsonCoercion code. (Fix 0002 is not needed anymore, because it is for
> >
Hi Nikita,
On Wed, Aug 24, 2022 at 6:29 AM Nikita Glukhov wrote:
> Here is my plan:
>
> 0. Take my last v7-0001 patch as a base. It already contains refactoring
> of JsonCoercion code. (Fix 0002 is not needed anymore, because it is for
> json[b] domains, which simply will not be supported.)
>
>
On 2022-08-23 Tu 17:29, Nikita Glukhov wrote:
>
>
> On 23.08.2022 22:31, Jonathan S. Katz wrote:
>> On 8/23/22 2:10 PM, Andrew Dunstan wrote:
>>>
>>> On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
> I saw Andrew suggest that the controversial parts of the patchset
>>
On 23.08.2022 22:31, Jonathan S. Katz wrote:
On 8/23/22 2:10 PM, Andrew Dunstan wrote:
On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
I saw Andrew suggest that the controversial parts of the patchset
may be
severable from some of the new functionality, so I would like t
Andrew Dunstan writes:
> On 2022-08-23 Tu 15:32, Jonathan S. Katz wrote:
>> On 8/23/22 1:26 PM, Andres Freund wrote:
>>> We could decide to revert this for 15, but leave it in tree for HEAD.
>> If it comes to that, I think that is a reasonable suggestion so long
>> as we're committed to making th
út 23. 8. 2022 v 21:54 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
> >> I agree with the upthread comments that we only need/want to catch
> >> foreseeable incorrect-input errors, and that the way to make that
> >> happen is to refactor t
Andres Freund writes:
> On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
>> I agree with the upthread comments that we only need/want to catch
>> foreseeable incorrect-input errors, and that the way to make that
>> happen is to refactor the related type input functions, and that
>> a lot of the heavy
On 2022-08-23 Tu 15:32, Jonathan S. Katz wrote:
> On 8/23/22 1:26 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
>>> Taking RMT hat off, if the outcome is "revert", I do want to ensure
>>> we don't
>>> lose momentum on getting this into v16. I know a l
On 8/23/22 1:26 PM, Andres Freund wrote:
Hi,
On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
Taking RMT hat off, if the outcome is "revert", I do want to ensure we don't
lose momentum on getting this into v16. I know a lot of time and effort has
gone into this featureset and it seems to b
On 8/23/22 2:10 PM, Andrew Dunstan wrote:
On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" writes:
I saw Andrew suggest that the controversial parts of the patchset may be
severable from some of the new functionality, so I would like to see
that proposal and if it is enough to overc
Hi,
On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
> I agree with the upthread comments that we only need/want to catch
> foreseeable incorrect-input errors, and that the way to make that
> happen is to refactor the related type input functions, and that
> a lot of the heavy lifting for that has be
Hi,
On 2022-08-23 13:33:42 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 1:23 PM Andres Freund wrote:
> > > But that's exactly what I'm complaining about. Catching an error that
> > > unwound a bunch of stack frames where complicated things are happening
> > > is fraught with peril. There's
On 23.08.2022 20:38, Pavel Stehule wrote:
út 23. 8. 2022 v 19:27 odesílatel Andres Freund
napsal:
Hi,
On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> The errors that should be handled are related to json structure
errors. I
> don't think so we have to handle all erro
On 2022-08-23 Tu 13:24, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> I saw Andrew suggest that the controversial parts of the patchset may be
>> severable from some of the new functionality, so I would like to see
>> that proposal and if it is enough to overcome concerns.
> It's an interest
Pavel Stehule writes:
> út 23. 8. 2022 v 19:27 odesílatel Andres Freund napsal:
>> I think that's not true unfortunately. You can specify return types, and
>> composite types can be populated. Which essentially requires arbitrary
>> coercions.
> Please, can you send an example? Maybe we try to f
út 23. 8. 2022 v 19:27 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> > The errors that should be handled are related to json structure errors. I
> > don't think so we have to handle all errors and all conversions.
> >
> > The JSON knows only three
On Tue, Aug 23, 2022 at 1:23 PM Andres Freund wrote:
> > But that's exactly what I'm complaining about. Catching an error that
> > unwound a bunch of stack frames where complicated things are happening
> > is fraught with peril. There's probably a bunch of errors that could
> > be thrown from some
Andres Freund writes:
> On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
>> But that's exactly what I'm complaining about. Catching an error that
>> unwound a bunch of stack frames where complicated things are happening
>> is fraught with peril. There's probably a bunch of errors that could
>> be
Hi,
On 2022-08-23 18:06:22 +0200, Pavel Stehule wrote:
> The errors that should be handled are related to json structure errors. I
> don't think so we have to handle all errors and all conversions.
>
> The JSON knows only three types - and these conversions can be written
> specially for this cas
Hi,
On 2022-08-23 13:18:49 -0400, Jonathan S. Katz wrote:
> Taking RMT hat off, if the outcome is "revert", I do want to ensure we don't
> lose momentum on getting this into v16. I know a lot of time and effort has
> gone into this featureset and it seems to be trending in the right
> direction. W
"Jonathan S. Katz" writes:
> I saw Andrew suggest that the controversial parts of the patchset may be
> severable from some of the new functionality, so I would like to see
> that proposal and if it is enough to overcome concerns.
It's an interesting suggestion. Do people have the cycles avail
Hi,
On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 11:55 AM Andres Freund wrote:
> > I don't think that's quite realistic - that's the input/output functions for
> > all types, basically. I'd be somewhat content if we'd a small list of very
> > common coercion paths w
On 8/23/22 11:08 AM, Tom Lane wrote:
Robert Haas writes:
At the end of the day, the RMT is going to have to take a call here.
It seems to me that Andres's concerns about code quality and lack of
comments are probably somewhat legitimate, and in particular I do not
think the use of subtransactio
On 23.08.2022 19:06, Pavel Stehule wrote:
Hi
út 23. 8. 2022 v 17:55 odesílatel Andres Freund
napsal:
Hi,
On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> I do not think that using subtransactions as part of the expression
> evaluation process is a sound idea pretty much u
On Tue, Aug 23, 2022 at 11:55 AM Andres Freund wrote:
> I don't think that's quite realistic - that's the input/output functions for
> all types, basically. I'd be somewhat content if we'd a small list of very
> common coercion paths we knew wouldn't error out, leaving things like OOM
> aside. Ev
Hi
út 23. 8. 2022 v 17:55 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> > I do not think that using subtransactions as part of the expression
> > evaluation process is a sound idea pretty much under any
> > circumstances. Maybe if the subtransation
Hi,
On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> I do not think that using subtransactions as part of the expression
> evaluation process is a sound idea pretty much under any
> circumstances. Maybe if the subtransations aren't commonly created and
> don't usually get XIDs there wouldn't be
On 2022-08-23 Tu 11:08, Tom Lane wrote:
> Robert Haas writes:
>> At the end of the day, the RMT is going to have to take a call here.
>> It seems to me that Andres's concerns about code quality and lack of
>> comments are probably somewhat legitimate, and in particular I do not
>> think the use
Hi,
On 2022-08-23 11:08:31 -0400, Tom Lane wrote:
> As you say, we've delegated this sort of decision to the RMT, but
> if I were on the RMT I'd be voting to revert.
Yea, I don't really see an alternative at this point. If we really wanted we
could try to cut the more complicated pieces out, e.g.
Robert Haas writes:
> At the end of the day, the RMT is going to have to take a call here.
> It seems to me that Andres's concerns about code quality and lack of
> comments are probably somewhat legitimate, and in particular I do not
> think the use of subtransactions is a good idea. I also don't
On Mon, Aug 22, 2022 at 9:52 PM Jonathan S. Katz wrote:
> > Andres, Robert: Do these changes address your concerns about the use of
> > substransactions and reduce the risk of xid wraparound?
>
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any thoug
On 8/23/22 12:13 AM, Michael Paquier wrote:
On Mon, Aug 22, 2022 at 07:57:29PM -0700, Andres Freund wrote:
To me it feels like there's a probably too much work here to cram it at this
point. If several other committers shared the load of working on this it'd
perhaps be doable, but I've not seen
On Tue, Aug 23, 2022 at 4:48 PM Amit Langote wrote:
> On Thu, Aug 18, 2022 at 12:46 PM Nikita Glukhov
> wrote:
> > The desciprion of the v7 patches:
> >
> > 0003 Add EEOP_SUBTRANS executor step
> > v6 + new recursive JIT
> >
> > 0004 Split JsonExpr execution into steps
> > simply rebase of v
Hi Nikita,
On Thu, Aug 18, 2022 at 12:46 PM Nikita Glukhov wrote:
> The desciprion of the v7 patches:
>
> 0001 Simplify JsonExpr execution
> Andres's changes + mine:
> - Added JsonCoercionType enum, fields like via_io replaced with it
> - Emit only context item steps in JSON_TABLE_OP case
>
On Mon, Aug 22, 2022 at 07:57:29PM -0700, Andres Freund wrote:
> To me it feels like there's a probably too much work here to cram it at this
> point. If several other committers shared the load of working on this it'd
> perhaps be doable, but I've not seen many volunteers.
While 0002 is dead simp
Hi,
On 2022-08-22 21:52:01 -0400, Jonathan S. Katz wrote:
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any thoughts on this current patch set?
To me it feels like there's a probably too much work here to cram it at this
point. If several other com
On Tue, Aug 23, 2022 at 10:52 AM Jonathan S. Katz wrote:
> Andres, Andrew, Amit, Robert -- as you have either worked on this or
> expressed opinions -- any thoughts on this current patch set?
FWIW, I've started looking at these patches.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
On 8/19/22 10:11 AM, Jonathan S. Katz wrote:
Hi,
On 8/17/22 11:45 PM, Nikita Glukhov wrote:
Hi,
On 17.08.2022 04:45, Jonathan S. Katz wrote:
On 8/15/22 10:14 PM, Andres Freund wrote:
I pushed a few cleanups to
https://github.com/anarazel/postgres/commits/json
while I was hacking on this (i
Hi,
On 8/17/22 11:45 PM, Nikita Glukhov wrote:
Hi,
On 17.08.2022 04:45, Jonathan S. Katz wrote:
On 8/15/22 10:14 PM, Andres Freund wrote:
I pushed a few cleanups to
https://github.com/anarazel/postgres/commits/json
while I was hacking on this (ignore that it's based on the meson
tree, that
Hi,
On 8/15/22 10:14 PM, Andres Freund wrote:
I pushed a few cleanups to https://github.com/anarazel/postgres/commits/json
while I was hacking on this (ignore that it's based on the meson tree, that's
just faster for me). Some of them might not be applicable anymore, but it
might still make sen
On Mon, Aug 15, 2022 at 6:39 PM Andres Freund wrote:
> I don't think it's sane from a performance view to start a subtransaction for
> every coercion, particularly because most coercion paths will never trigger an
> error, leaving things like out-of-memory or interrupts aside. And those are
> re-t
Hi,
On 2022-08-16 04:02:17 +0300, Nikita Glukhov wrote:
> Hi,
>
>
> On 16.08.2022 01:38, Andres Freund wrote:
> > Continuation from the thread at
> > https://postgr.es/m/20220811171740.m5b4h7x63g4lzgrk%40awork3.anarazel.de
> >
> >
> > I started hacking on this Friday. I think there's some relativ
Hi,
On 2022-08-15 15:38:53 -0700, Andres Freund wrote:
> Next question:
>
> /*
>* We should catch exceptions of category ERRCODE_DATA_EXCEPTION and
>* execute the corresponding ON ERROR behavior then.
>*/
> oldcontext = CurrentMemoryContext;
> oldowner =
Hi,
Continuation from the thread at
https://postgr.es/m/20220811171740.m5b4h7x63g4lzgrk%40awork3.anarazel.de
On 2022-08-11 10:17:40 -0700, Andres Freund wrote:
> On 2022-08-11 13:08:27 -0400, Jonathan S. Katz wrote:
> > With RMT hat on, Andres do you have any thoughts on this?
>
> I think I ne
On 8/10/22 11:50 AM, Andrew Dunstan wrote:
On 2022-08-09 Tu 16:58, Jonathan S. Katz wrote:
Hi,
(Personal hat, not RMT hat unless otherwise noted).
This thread[1] raised some concerns around the implementation of the
SQL/JSON features that are slated for v15, which includes an
outstanding open
On 2022-08-09 Tu 16:58, Jonathan S. Katz wrote:
> Hi,
>
> (Personal hat, not RMT hat unless otherwise noted).
>
> This thread[1] raised some concerns around the implementation of the
> SQL/JSON features that are slated for v15, which includes an
> outstanding open item[2]. Given the current state
On 8/9/22 4:58 PM, Jonathan S. Katz wrote:
We're looking for additional input on what makes sense as a best course
of action, given what is presented in[3].
Missed adding Amit on the CC.
Jonathan
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
(Personal hat, not RMT hat unless otherwise noted).
This thread[1] raised some concerns around the implementation of the
SQL/JSON features that are slated for v15, which includes an outstanding
open item[2]. Given the current state of the discussion, when the RMT
met on Aug 8, they severa
89 matches
Mail list logo
