út 19. 1. 2021 v 19:21 odesílatel Pavel Stehule
napsal:
> Hi
>
> Now, I am testing subscribing on the jsonb feature, and I found one issue,
> that is not supported by parser.
>
> When the target is scalar, then all is ok. But we can have a plpgsql array
> of jsonb values.
>
> postgres=# do $$
> d
Hi
Now, I am testing subscribing on the jsonb feature, and I found one issue,
that is not supported by parser.
When the target is scalar, then all is ok. But we can have a plpgsql array
of jsonb values.
postgres=# do $$
declare j jsonb[];
begin
j[1] = '{"b":"Ahoj"}';
raise notice '%', j;
r
ne 3. 1. 2021 v 19:07 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I found inconsistency in work with slicings (this is not directly related
> > to this patch, but can be interesting, because with new functionality the
> > array slicings can be edited more often).
>
> > a = array[1,2,
Pavel Stehule writes:
> I found inconsistency in work with slicings (this is not directly related
> to this patch, but can be interesting, because with new functionality the
> array slicings can be edited more often).
> a = array[1,2,3,4,5];
> a[1:5] = 10; -- correctly fails, although for some pe
Hi
I continue in review.
I found inconsistency in work with slicings (this is not directly related
to this patch, but can be interesting, because with new functionality the
array slicings can be edited more often).
a = array[1,2,3,4,5];
a[1:5] = 10; -- correctly fails, although for some people c
po 28. 12. 2020 v 0:55 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Now, the behavior of SELECT INTO is behind the assign statement and this
> > fact should be documented. Usually we don't need to use array's fields
> > here, but somebody can try it.
>
> It's been behind all along --
Pavel Stehule writes:
> Now, the behavior of SELECT INTO is behind the assign statement and this
> fact should be documented. Usually we don't need to use array's fields
> here, but somebody can try it.
It's been behind all along --- this patch didn't really change that.
But I don't mind documen
so 26. 12. 2020 v 19:00 odesílatel Pavel Stehule
napsal:
> Hi
>
> I repeated tests. I wrote a set of simple functions. It is a synthetical
> test, but I think it can identify potential problems well.
>
> I calculated the average of 3 cycles and I checked the performance of each
> function. I didn
Hi
I repeated tests. I wrote a set of simple functions. It is a synthetical
test, but I think it can identify potential problems well.
I calculated the average of 3 cycles and I checked the performance of each
function. I didn't find any problem. The total execution time is well too.
Patched code
út 15. 12. 2020 v 21:18 odesílatel Tom Lane napsal:
> I realized that the speedup patch I posted yesterday is flawed: it's
> too aggressive about applying the R/W param mechanism, instead of
> not aggressive enough.
>
> To review, the point of that logic is that if we have an assignment
> like
>
I realized that the speedup patch I posted yesterday is flawed: it's
too aggressive about applying the R/W param mechanism, instead of
not aggressive enough.
To review, the point of that logic is that if we have an assignment
like
arrayvar := array_append(arrayvar, some-scalar-expression);
po 14. 12. 2020 v 17:25 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I checked a performance and it looks so access to record's field is
> faster,
> > but an access to arrays field is significantly slower
>
> Hmm, I'd drawn the opposite conclusion in my own testing ...
>
> > for i
Pavel Stehule writes:
> I checked a performance and it looks so access to record's field is faster,
> but an access to arrays field is significantly slower
Hmm, I'd drawn the opposite conclusion in my own testing ...
> for i in 1..5000
> loop
> if a[i] > a[i+1] then
> aux :
Hi
I checked a performance and it looks so access to record's field is faster,
but an access to arrays field is significantly slower
do $$
declare
a int[];
aux int;
rep boolean default true;
begin
for i in 1..5000
loop
a[i]:= 5000 - i;
end loop;
raise notice '%', a[1:10];
wh
ne 13. 12. 2020 v 22:41 odesílatel Tom Lane napsal:
> I wrote:
> > So my idea here is to add a parsing-mode option to raw_parser(),
> > which would be an enum with values like "normal SQL statement",
> > "expression only", "type name", "plpgsql assignment statement".
>
> Here's a fleshed-out patc
I wrote:
> So my idea here is to add a parsing-mode option to raw_parser(),
> which would be an enum with values like "normal SQL statement",
> "expression only", "type name", "plpgsql assignment statement".
Here's a fleshed-out patch series that attacks things that way.
I'm a lot better pleased w
I wrote:
> In any case, that approach still involves inserting some query text
> that the user didn't write, so I'm not sure how much confusion it'd
> remove. The "SET n:" business at least looks like it's some weird
> prefix comparable to "LINE n:", so while people wouldn't understand
> it I thin
Chapman Flack writes:
> On 12/11/20 12:21, Tom Lane wrote:
>> solution I adopted was just to invent a new CoercionContext value
>> COERCION_PLPGSQL, representing "use pl/pgsql's rules". (Basically
>> what that means nowadays is to apply CoerceViaIO if assignment cast
>> lookup doesn't find a cast
Hi
It is great. I expected much more work.
pá 11. 12. 2020 v 18:21 odesílatel Tom Lane napsal:
> We've had complaints in the past about how plpgsql can't handle
> assignments to fields in arrays of records [1], that is cases like
>
> arrayvar[n].field := something;
>
> and also complain
On 12/11/20 12:21, Tom Lane wrote:
> solution I adopted was just to invent a new CoercionContext value
> COERCION_PLPGSQL, representing "use pl/pgsql's rules". (Basically
> what that means nowadays is to apply CoerceViaIO if assignment cast
> lookup doesn't find a cast pathway.)
That seems like a
We've had complaints in the past about how plpgsql can't handle
assignments to fields in arrays of records [1], that is cases like
arrayvar[n].field := something;
and also complaints about how plpgsql can't handle assignments
to array slices [2], ie
arrayvar[m:n] := something;
A
21 matches
Mail list logo
