> On Fri, Jan 29, 2021 at 7:01 PM Alexander Korotkov
> wrote:
> Pushed with minor cleanup.
Thanks a lot!
> On Sun, Jan 31, 2021 at 05:23:25PM -0500, Tom Lane wrote:
>
> thorntail seems unhappy:
>
> [From 7c5d57c...]
> Fix portability issue in new jsonbsubs code.
>
> On machines where
Alexander Korotkov writes:
> Pushed with minor cleanup.
thorntail seems unhappy:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail=2021-01-31%2020%3A58%3A12
==-=-== stack trace: pgsql.build/src/test/regress/tmp_check/data/core
==-=-==
[New LWP 2266507]
[Thread
On Fri, Jan 29, 2021 at 7:01 PM Alexander Korotkov wrote:
> On Thu, Jan 21, 2021 at 11:14 PM Pavel Stehule
> wrote:
> >> Looks good, I've applied it, thanks.
> >
> > I tested last set of patches
> >
> > 1. There is no problem with patching and compilation
> > 2. make check-world passed
> > 3.
On Thu, Jan 21, 2021 at 11:14 PM Pavel Stehule wrote:
>> Looks good, I've applied it, thanks.
>
> I tested last set of patches
>
> 1. There is no problem with patching and compilation
> 2. make check-world passed
> 3. build doc without problems
> 4. I have not any objections against implemented
Hi
> Looks good, I've applied it, thanks.
>
I tested last set of patches
1. There is no problem with patching and compilation
2. make check-world passed
3. build doc without problems
4. I have not any objections against implemented functionality,
implementation and tests
I'll mark this patch
> On Wed, Jan 20, 2021 at 11:37:32PM -0500, Dian M Fay wrote:
> On Wed Jan 20, 2021 at 2:08 PM EST, Dmitry Dolgov wrote:
> > > On Wed, Jan 20, 2021 at 11:34:16AM -0500, Dian M Fay wrote:
> > > > Thanks, I need to remember to not skipp doc building for testing process
> > > > even for such small
On Wed Jan 20, 2021 at 2:08 PM EST, Dmitry Dolgov wrote:
> > On Wed, Jan 20, 2021 at 11:34:16AM -0500, Dian M Fay wrote:
> > > Thanks, I need to remember to not skipp doc building for testing process
> > > even for such small changes. Hope now I didn't forget anything.
> > >
> > > > On Wed, Jan
> On Wed, Jan 20, 2021 at 11:34:16AM -0500, Dian M Fay wrote:
> > Thanks, I need to remember to not skipp doc building for testing process
> > even for such small changes. Hope now I didn't forget anything.
> >
> > > On Wed, Jan 20, 2021 at 09:58:43AM -0500, Dian M Fay wrote:
> >
> > > Here's a
On Wed Jan 20, 2021 at 11:22 AM EST, Dmitry Dolgov wrote:
> > On Tue Jan 19, 2021 at 1:42 PM EST, Pavel Stehule wrote:
> >
> > I found minor issues.
> >
> > Doc - missing tag
> >
> > and three whitespaces issues
> >
> > see attached patch
>
> Thanks, I need to remember to not skipp doc building
> On Tue Jan 19, 2021 at 1:42 PM EST, Pavel Stehule wrote:
>
> I found minor issues.
>
> Doc - missing tag
>
> and three whitespaces issues
>
> see attached patch
Thanks, I need to remember to not skipp doc building for testing process
even for such small changes. Hope now I didn't forget
On Tue Jan 19, 2021 at 1:42 PM EST, Pavel Stehule wrote:
> Hi
>
> I found minor issues.
>
> Doc - missing tag
>
> and three whitespaces issues
>
> see attached patch
>
> Following sentence is hard to read due long nested example
>
> If the
> + path contradicts structure of modified jsonb for any
>
Hi
I found minor issues.
Doc - missing tag
and three whitespaces issues
see attached patch
Following sentence is hard to read due long nested example
If the
+ path contradicts structure of modified jsonb for any
individual
+ value (e.g. path val['a']['b']['c'] assumes keys
+ 'a' and
> On Thu, Jan 14, 2021 at 12:02:42PM -0500, Dian M Fay wrote:
> > Other than that, since I've already posted the patch for returning an
> > error option, it seems that the only thing left is to decide with which
> > version to go.
>
> The trigger issue (which I did verify) makes the "no update"
čt 14. 1. 2021 v 18:09 odesílatel Dian M Fay napsal:
> On Thu Jan 14, 2021 at 10:04 AM EST, Dmitry Dolgov wrote:
> > > On Tue, Jan 12, 2021 at 08:02:59PM +0100, Pavel Stehule wrote:
> > > ne 10. 1. 2021 v 19:52 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com>
> > > napsal:
> > >
> > > I
On Thu Jan 14, 2021 at 10:04 AM EST, Dmitry Dolgov wrote:
> > On Tue, Jan 12, 2021 at 08:02:59PM +0100, Pavel Stehule wrote:
> > ne 10. 1. 2021 v 19:52 odesílatel Pavel Stehule
> > napsal:
> >
> > I tested behaviour and I didn't find anything other than the mentioned
> > issue.
> >
> > Now I can
> On Tue, Jan 12, 2021 at 08:02:59PM +0100, Pavel Stehule wrote:
> ne 10. 1. 2021 v 19:52 odesílatel Pavel Stehule
> napsal:
>
> I tested behaviour and I didn't find anything other than the mentioned
> issue.
>
> Now I can check this feature from plpgsql, and it is working. Because there
> is no
ne 10. 1. 2021 v 19:52 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>> I'm thinking of the update path as a kind of implicit schema. JSON is
>> intentionally not bound to any schema on creation, so I don't see a
>> failure to enforce another schema at runtime (and outside the WHERE
>> clause, at
Hi
> I'm thinking of the update path as a kind of implicit schema. JSON is
> intentionally not bound to any schema on creation, so I don't see a
> failure to enforce another schema at runtime (and outside the WHERE
> clause, at that) as an error exactly.
>
This concept is not consistent with
On Sat Jan 9, 2021 at 3:34 PM EST, Pavel Stehule wrote:
> so 9. 1. 2021 v 21:06 odesílatel Dian M Fay
> napsal:
>
> > On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > > napsal:
> > >
> > > > > On Wed, Jan 06,
so 9. 1. 2021 v 21:06 odesílatel Dian M Fay napsal:
> On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > > >
> > > > this case
On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > >
> > > this case should to raise exception - the value should be changed or
> >
čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> >
> > this case should to raise exception - the value should be changed or
> error
> > should be raised
> >
> > postgres=# insert into foo
> On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
>
> this case should to raise exception - the value should be changed or error
> should be raised
>
> postgres=# insert into foo values('{}');
> postgres=# update foo set a['a'] = '100';
> postgres=# update foo set a['a'][1] = '-1';
Hi
út 5. 1. 2021 v 20:32 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jan 04, 2021 at 06:56:17PM +0100, Pavel Stehule wrote:
> > po 4. 1. 2021 v 14:58 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> > postgres=# update foo set a['c']['c'][10] = '10';
> >
> On Mon, Jan 04, 2021 at 06:56:17PM +0100, Pavel Stehule wrote:
> po 4. 1. 2021 v 14:58 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
> postgres=# update foo set a['c']['c'][10] = '10';
> postgres=# update foo set a['c'][10][10] = '10';
Yeah, there was one clumsy memory allocation.
po 4. 1. 2021 v 14:58 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Jan 03, 2021 at 08:41:17PM +0100, Pavel Stehule wrote:
> >
> > probably some is wrong still
> >
> > create table foo(a jsonb);
> > update foo set a['a'] = '10';
> > update foo set a['b']['c'][1] = '10';
> >
> On Sun, Jan 03, 2021 at 08:41:17PM +0100, Pavel Stehule wrote:
>
> probably some is wrong still
>
> create table foo(a jsonb);
> update foo set a['a'] = '10';
> update foo set a['b']['c'][1] = '10';
> update foo set a['b']['c'][10] = '10'
Thanks for noticing. Indeed, there was a subtle change
Hi
probably some is wrong still
create table foo(a jsonb);
update foo set a['a'] = '10';
update foo set a['b']['c'][1] = '10';
update foo set a['b']['c'][10] = '10'
WARNING: problem in alloc set ExprContext: req size > alloc size for chunk
0x256dd88 in block 0x256d160
WARNING: problem in
> On Thu, Dec 31, 2020 at 08:21:55PM +0100, Pavel Stehule wrote:
> čt 31. 12. 2020 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> the tests passed and filling gaps works well
>
> but creating empty objects doesn't work
>
> create table foo(a jsonb);
>
> insert into foo
čt 31. 12. 2020 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Dec 30, 2020 at 09:01:37PM +0100, Dmitry Dolgov wrote:
> > > make check fails
> >
> > Yeah, apparently I forgot to enable asserts back after the last
> > benchmarking discussion, and missed some of those.
> On Wed, Dec 30, 2020 at 09:01:37PM +0100, Dmitry Dolgov wrote:
> > make check fails
>
> Yeah, apparently I forgot to enable asserts back after the last
> benchmarking discussion, and missed some of those. Will fix.
>
> > 2. The index position was ignored.
> >
> > postgres=# update foo set
> On Wed, Dec 30, 2020 at 07:48:57PM +0100, Pavel Stehule wrote:
> st 30. 12. 2020 v 14:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> > > >
> >
st 30. 12. 2020 v 14:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> > >
> > > In a case like jsonpath['...'], the initially UNKNOWN-type literal
>
> On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> >
> > In a case like jsonpath['...'], the initially UNKNOWN-type literal could
> > in theory be coerced to any of these types, so you'd have to resolve that
> > case
> On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
>
> In a case like jsonpath['...'], the initially UNKNOWN-type literal could
> in theory be coerced to any of these types, so you'd have to resolve that
> case manually. The overloaded-function code has an internal preference
> that
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Tue, Dec 22, 2020 at 02:21:22PM -0500, Tom Lane wrote:
>> We do have precedent for this, it's the rules about resolving argument
>> types for overloaded functions. But the conclusion that that precedent
>> leads to is that we should check
> On Tue, Dec 22, 2020 at 02:21:22PM -0500, Tom Lane wrote:
> Pavel Stehule writes:
> > But maybe we try to design some that are designed already. Is there some
> > info about index specification in SQL/JSON?
>
> We do have precedent for this, it's the rules about resolving argument
> types for
Pavel Stehule writes:
> But maybe we try to design some that are designed already. Is there some
> info about index specification in SQL/JSON?
We do have precedent for this, it's the rules about resolving argument
types for overloaded functions. But the conclusion that that precedent
leads to
út 22. 12. 2020 v 18:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, Dec 22, 2020 at 11:57:13AM -0500, Tom Lane wrote:
> > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
> > >> I expect behave like
> > >>
> On Tue, Dec 22, 2020 at 11:57:13AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
> >> I expect behave like
> >>
> >> update x set test[1] = 10; --> "[10]";
> >> update x set test['1'] = 10; --> "{"1":
út 22. 12. 2020 v 17:57 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
> >> I expect behave like
> >>
> >> update x set test[1] = 10; --> "[10]";
> >> update x set test['1'] = 10; --> "{"1": 10}"
>
>
Dmitry Dolgov <9erthali...@gmail.com> writes:
> On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
>> I expect behave like
>>
>> update x set test[1] = 10; --> "[10]";
>> update x set test['1'] = 10; --> "{"1": 10}"
> Yes, I also was thinking about this because such behaviour is more
> On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
>
> > Here is the new version of jsonb subscripting rebased on the committed
> > infrastructure patch. I hope it will not introduce any confusion with
> > the previously posted patched in this thread (about alter type subscript
> >
út 22. 12. 2020 v 11:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Dec 18, 2020 at 08:59:25PM +0100, Dmitry Dolgov wrote:
> > > On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> > > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > > > On Thu, Dec 17, 2020 at
> On Fri, Dec 18, 2020 at 08:59:25PM +0100, Dmitry Dolgov wrote:
> > On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > > On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
> > >> We can certainly reconsider the API for the
> On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
> >> We can certainly reconsider the API for the parsing hook if there's
> >> really a good reason for these to be different
čt 17. 12. 2020 v 22:47 odesílatel Tom Lane napsal:
> Chapman Flack writes:
> > That's likely to be what a programmer intends when writing
> > (variable explicitly typed integer) := js['n'] and
> > (variable explicitly types varchar) := js['v']
>
> I think that what we want, if we're to support
On 12/17/20 16:56, Chapman Flack wrote:
>> that, it's called a cast.
>
> I find them different; XQuery was the first language I had encountered
> that provides both (a cast in XQuery is spelled 'cast as', just as you'd
> expect), and the idea of an explicit operation that means "I am only
>
On 12/17/20 16:47, Tom Lane wrote:
> As far as "treat as" is concerned, we already have a spelling for
> that, it's called a cast.
I find them different; XQuery was the first language I had encountered
that provides both (a cast in XQuery is spelled 'cast as', just as you'd
expect), and the idea
Chapman Flack writes:
> That's likely to be what a programmer intends when writing
> (variable explicitly typed integer) := js['n'] and
> (variable explicitly types varchar) := js['v']
I think that what we want, if we're to support that sort of thing,
is that the js[] constructs produce jsonb by
On 12/17/20 15:50, Tom Lane wrote:
> Chapman Flack writes:
>> On 12/17/20 14:28, Tom Lane wrote:
>>> If you're imagining that js['n'] and js['v'] would emit different
>>> datatypes, forget it. That would require knowing at parse time
>>> what the structure of the json object will be at run time.
Chapman Flack writes:
> On 12/17/20 14:28, Tom Lane wrote:
>> If you're imagining that js['n'] and js['v'] would emit different
>> datatypes, forget it. That would require knowing at parse time
>> what the structure of the json object will be at run time.
> Would it be feasible to analyze that
Dmitry Dolgov <9erthali...@gmail.com> writes:
> On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
>> We can certainly reconsider the API for the parsing hook if there's
>> really a good reason for these to be different types, but it seems
>> like that would just be encouraging poor design.
čt 17. 12. 2020 v 20:28 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal:
> >> So ... what's the problem with that? Seems like what you should put
> >> in and what you should get out should be the same type.
>
> > I don't think so.
On 12/17/20 14:28, Tom Lane wrote:
> Pavel Stehule writes:
>> n int;
>> v varchar;
>> js jsonb default '{"n": 100, "v" : "Hello"};
>> BEGIN
>> n := js['n'];
>> v := js['v'];
>
> If you're imagining that js['n'] and js['v'] would emit different
> datatypes, forget it. That would
> On Thu, Dec 17, 2020 at 01:49:17PM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > While rebasing the jsonb patch I found out that the current subscripting
> > assignment implementation in transformAssignmentIndirection always
> > coerce the value to be assigned to the
Pavel Stehule writes:
> čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal:
>> So ... what's the problem with that? Seems like what you should put
>> in and what you should get out should be the same type.
> I don't think so. For XML or JSON the target can be different, and it can
> safe one
čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > While rebasing the jsonb patch I found out that the current subscripting
> > assignment implementation in transformAssignmentIndirection always
> > coerce the value to be assigned to the type
Dmitry Dolgov <9erthali...@gmail.com> writes:
> While rebasing the jsonb patch I found out that the current subscripting
> assignment implementation in transformAssignmentIndirection always
> coerce the value to be assigned to the type which subscripting result
> suppose to have (refrestype). For
> On Fri, Dec 11, 2020 at 10:38:07AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Wed, Dec 09, 2020 at 04:59:34PM -0500, Tom Lane wrote:
> >> 0001 adds the ability to attach a subscript handler to an existing
> >> data type with ALTER TYPE. This is clearly going
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Wed, Dec 09, 2020 at 04:59:34PM -0500, Tom Lane wrote:
>> 0001 adds the ability to attach a subscript handler to an existing
>> data type with ALTER TYPE. This is clearly going to be necessary
>> if we want extension types to be able to use this
> On Wed, Dec 09, 2020 at 04:59:34PM -0500, Tom Lane wrote:
>
> 0001 adds the ability to attach a subscript handler to an existing
> data type with ALTER TYPE. This is clearly going to be necessary
> if we want extension types to be able to use this facility. The
> only thing that I think might
On Wed, Dec 09, 2020 at 12:49:48PM -0500, Tom Lane wrote:
> I've pushed the core patch now. The jsonb parts now have to be
> rebased onto this design, which I'm assuming Dmitry will tackle
> (I do not intend to). It's not quite clear to me whether we have
> a meeting of the minds on what the
st 9. 12. 2020 v 22:59 odesílatel Tom Lane napsal:
> Here's a couple of little finger exercises to move this along a bit.
>
> 0001 adds the ability to attach a subscript handler to an existing
> data type with ALTER TYPE. This is clearly going to be necessary
> if we want extension types to be
Here's a couple of little finger exercises to move this along a bit.
0001 adds the ability to attach a subscript handler to an existing
data type with ALTER TYPE. This is clearly going to be necessary
if we want extension types to be able to use this facility. The
only thing that I think might
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Wed, Dec 09, 2020 at 12:49:48PM -0500, Tom Lane wrote:
>> I'd be happier if the "container" terminology were reserved for
>> that sort of physical containment, which means that I think a lot
>> of the commentary around SubscriptingRef is
> On Wed, Dec 09, 2020 at 12:49:48PM -0500, Tom Lane wrote:
>
> I've pushed the core patch now.
Thanks a lot!
> The jsonb parts now have to be
> rebased onto this design, which I'm assuming Dmitry will tackle
Yes, I'm already on it, just couldn't keep up with the changes in this
thread.
> BTW,
I've pushed the core patch now. The jsonb parts now have to be
rebased onto this design, which I'm assuming Dmitry will tackle
(I do not intend to). It's not quite clear to me whether we have
a meeting of the minds on what the jsonb functionality should be,
anyway. Alexander seemed to be
On 2020-12-08 22:02:24 -0500, Tom Lane wrote:
> BTW, I observe that with MAXDIM gone from execExpr.h, there are
> no widely-visible uses of MAXDIM except for array.h. I therefore
> suggest that we should pull "#define MAXDIM" out of c.h and put it
> into array.h, as attached. I was slightly
BTW, I observe that with MAXDIM gone from execExpr.h, there are
no widely-visible uses of MAXDIM except for array.h. I therefore
suggest that we should pull "#define MAXDIM" out of c.h and put it
into array.h, as attached. I was slightly surprised to find that
this seems to entail *no* new
Andres Freund writes:
> On 2020-12-08 11:05:05 -0500, Tom Lane wrote:
>> Other than that nit, please finish this up and push it so I can finish
>> the generic-subscripting patch.
> Done.
Cool, thanks. I'll fix that part of the generic-subscript patch
and push it tomorrow, unless somebody
Hi,
On 2020-12-08 11:05:05 -0500, Tom Lane wrote:
> I've now studied this patch and it seems sane to me, although
> I wondered why you wrote "extern"s here:
Brainfart...
> Other than that nit, please finish this up and push it so I can finish
> the generic-subscripting patch.
Done.
> > WRT
Andres Freund writes:
> On 2020-12-07 17:25:41 -0500, Tom Lane wrote:
>> I can see that that should work for the two existing implementations
>> of EEO_CASE, but I wasn't sure if you wanted to wire in an assumption
>> that it'll always work.
> I don't think it's likely to be a problem, and if it
Andres Freund writes:
> I've attached a prototype conversion for two other such places. Which
> immediately pointed to a bug. And one harmless issue (using a pointer to
> size_t instead of ExprEvalOp* to represent the 'op' parameter), which
> you promptly copied...
> If I pushed a slightly
Hi,
On 2020-12-07 17:25:41 -0500, Tom Lane wrote:
> Fair enough. It wasn't entirely clear to me whether it'd be kosher to
> write
> EEO_CASE(EEOP_SBSREF_OLD)
> EEO_CASE(EEOP_SBSREF_ASSIGN)
> EEO_CASE(EEOP_SBSREF_FETCH)
> {
>
Andres Freund writes:
> On 2020-12-07 16:32:32 -0500, Tom Lane wrote:
>> What did you think of the idea of merging EEOP_SBSREF_OLD / ASSIGN / FETCH
>> into a single step type distinguished only by the callback function?
> I don't have a strong opinion on this. I guess find it a bit easier to
>
Hi,
On 2020-12-07 16:32:32 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think it'd be a better to rely on the backend's definition of
> > ExecEvalBoolSubroutine etc. For the functions implementing expression
> > steps I've found that far easier to work with over time (because you can
> >
Andres Freund writes:
> The TypeParamBool stuff here is ok. Basically LLVM uses a '1bit' integer
> to represent booleans in the IR. But when it comes to storing such a
> value in memory, it uses 1 byte, for obvious reasons. Hence the two
> types.
Cool, thanks for taking a look.
> I think it'd
Hi,
On 2020-12-07 14:08:35 -0500, Tom Lane wrote:
> 1. I'm still wondering if TypeParamBool is the right thing to pass to
> LLVMFunctionType() to describe a function-returning-bool. It does
> seem to work on x64_64 and aarch64, for what that's worth.
> -
I decided that the way to get this moved forward is to ignore the jsonb
parts for the moment and focus on getting the core feature into
committable shape. It's possible that the lack of a concrete use-case
other than arrays will cause us to miss a detail or two, but if so we
can fix it later, I
BTW, I had a thought about this patch, which I wanted to write down
before it disappears again (I'm not offering to code it right now).
I think we should split array_subscript_handler into two functions,
one for "regular" varlena arrays and one for the fixed-length
pseudo-array types like "name"
Pavel Stehule writes:
> I tested the last patch on my FC33 Lenovo T520 (I7) and I don't see 15%
> slowdown too .. On my comp there is a slowdown of about 1.5-3%. I used your
> function arraytest.
After repeating the experiment a few times, I think I was misled
by ASLR variance (ie, hot code
Alexander Korotkov writes:
> I didn't get we can't add opaque field to SubscriptingRefState without
> adding it to SubscriptingRef, which has to support
> copy/compare/outfuncs/readfuncs
Umm ... all depends on what you envision putting in there. There
certainly can be an opaque field in
On Wed, Dec 2, 2020 at 10:18 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Wed, Dec 02, 2020 at 11:52:54AM -0500, Tom Lane wrote:
> > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > >> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
> > >>> On Mon, Nov 30, 2020 at
st 2. 12. 2020 v 21:02 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> >> So ... one of the things that's been worrying me about this patch
> >> from day one is whether it would create a noticeable
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
>> So ... one of the things that's been worrying me about this patch
>> from day one is whether it would create a noticeable performance
>> penalty for existing use-cases. I did a small
> On Wed, Dec 02, 2020 at 01:20:10PM -0600, Justin Pryzby wrote:
> On Wed, Dec 02, 2020 at 08:18:08PM +0100, Dmitry Dolgov wrote:
> > > On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> > > So ... one of the things that's been worrying me about this patch
> > > from day one is whether it
On Wed, Dec 02, 2020 at 08:18:08PM +0100, Dmitry Dolgov wrote:
> > On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> > So ... one of the things that's been worrying me about this patch
> > from day one is whether it would create a noticeable performance
> > penalty for existing
> On Wed, Dec 02, 2020 at 11:52:54AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
> >>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
> >>> The idea of an opaque field in
> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> So ... one of the things that's been worrying me about this patch
> from day one is whether it would create a noticeable performance
> penalty for existing use-cases. I did a small amount of experimentation
> about that with the v35
So ... one of the things that's been worrying me about this patch
from day one is whether it would create a noticeable performance
penalty for existing use-cases. I did a small amount of experimentation
about that with the v35 patchset, and it didn't take long at all to
find that this:
--- cut
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
>>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
>>> The idea of an opaque field in SubscriptingRef structure is more
>>> attractive to me. Could you please
> On Mon, Nov 30, 2020 at 02:26:19PM +0100, Dmitry Dolgov wrote:
> > On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
> >
> > > > My first question is whether we're
> > > > able to handle different subscript types differently. For instance,
> > > > one day we could handle
> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
>
> > > My first question is whether we're
> > > able to handle different subscript types differently. For instance,
> > > one day we could handle jsonpath subscripts for jsonb. And for sure,
> > > jsonpath subscripts are
On Mon, Nov 30, 2020 at 2:33 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Fri, Nov 27, 2020 at 12:13:48PM +0300, Alexander Korotkov wrote:
> > I've started to review this patch.
>
> Thanks!
>
> > My first question is whether we're
> > able to handle different subscript types differently.
> On Fri, Nov 27, 2020 at 12:13:48PM +0300, Alexander Korotkov wrote:
>
> Hi!
>
> I've started to review this patch.
Thanks!
> My first question is whether we're
> able to handle different subscript types differently. For instance,
> one day we could handle jsonpath subscripts for jsonb. And
Hi!
I've started to review this patch. My first question is whether we're
able to handle different subscript types differently. For instance,
one day we could handle jsonpath subscripts for jsonb. And for sure,
jsonpath subscripts are expected to be handled differently from text
subscripts. I
po 28. 9. 2020 v 11:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Sep 25, 2020 at 06:43:38PM +0200, Pavel Stehule wrote:
> >
> > I checked this set of patches and it looks well.
> >
> > I have only one minor comment. I understand the error message, but I am
> not
> >
> On Fri, Sep 25, 2020 at 06:43:38PM +0200, Pavel Stehule wrote:
>
> I checked this set of patches and it looks well.
>
> I have only one minor comment. I understand the error message, but I am not
> sure if without deeper knowledge I can understand.
>
> +update test_jsonb_subscript set
ne 20. 9. 2020 v 17:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Sep 18, 2020 at 07:23:11PM +0200, Pavel Stehule wrote:
> >
> > > In this way (returning an error on a negative indices bigger than the
> > > number of elements) functionality for assigning via subscripting
1 - 100 of 178 matches
Mail list logo
