> Attached are the v30 patches, just adding a patch to change the
> default io_method parameter to sync, expecting this affects something
> to the recent CFbot failure.
> https://commitfest.postgresql.org/patch/4460/
> https://cirrus-ci.com/task/6078653164945408
> which is similar to:
> https://www
On Tue, Oct 22, 2024 at 6:12 AM Vik Fearing wrote:
>
> On 22/10/2024 12:19, Tatsuo Ishii wrote:
>
> Acording to ISO/IEC 9075-2:2016 "4.21.2 Row pattern navigation operations",
>
>evaluates a VE
> in a row NR, which may be different than current row CR.
>
> From this I think PREV(col + 1) s
On 22/10/2024 12:19, Tatsuo Ishii wrote:
Acording to ISO/IEC 9075-2:2016 "4.21.2 Row pattern navigation operations",
evaluates a VE
in a row NR, which may be different than current row CR.
From this I think PREV(col + 1) should be interpreted as:
1. go to the previous row.
2. evaluat
> On Monday, October 21, 2024, Tatsuo Ishii wrote:
>>
>> I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
>> Currently my RPR implementation does not allow PREV(col + 1). If
>> "PREV(col + 1)" is different from "PREV(col) + 1", it maybe worthwhile
>> to implement "PREV(col + 1)".
>>
On Monday, October 21, 2024, Tatsuo Ishii wrote:
>
> I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
> Currently my RPR implementation does not allow PREV(col + 1). If
> "PREV(col + 1)" is different from "PREV(col) + 1", it maybe worthwhile
> to implement "PREV(col + 1)".
>
Intere
Hi,
I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
Currently my RPR implementation does not allow PREV(col + 1). If
"PREV(col + 1)" is different from "PREV(col) + 1", it maybe worthwhile
to implement "PREV(col + 1)".
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www
On Sun, Sep 29, 2024 at 5:08 PM Tatsuo Ishii wrote:
> > I think implementing MEASURES is challenging. Especially we need to
> > find how our parser accepts "colname OVER
> > window_definition". Currently PostgreSQL's parser only accepts "func()
> > OVER window_definition" Even it is technically po
>> While playing with the feature, I've been trying to identify runs of
>> matched rows by eye. But it's pretty difficult -- the best I can do is
>> manually count rows using a `COUNT(*) OVER ...`. So I'd like to
>> suggest that MEASURES be part of the eventual v1 feature, if there's
>> no other wa
> With some bigger partitions, I hit an `ERROR: wrong pos: 1024`. A
> test that reproduces it is attached.
Thanks for the report. Attached is a patch on top of v22 patches to
fix the bug. We keep info in an array
(WindowAggState.reduced_frame_map) to track the rpr pattern match
result status for
On Wed, Sep 18, 2024 at 10:00 PM Tatsuo Ishii wrote:
>
> Attached are the v22 patches. Just rebased.
Thanks!
With some bigger partitions, I hit an `ERROR: wrong pos: 1024`. A
test that reproduces it is attached.
While playing with the feature, I've been trying to identify runs of
matched rows
I gave a talk on RPR in PGConf.dev 2024.
https://www.pgevents.ca/events/pgconfdev2024/schedule/session/114-implementing-row-pattern-recognition/
(Slides are available from the link).
Vik Faring and Jacob Champion were one of the audiences and we had a
small discussion after the talk. We continued
> On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
>> SELECT v.a, count(*) OVER w
>> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
>> WINDOW w AS (
>> ORDER BY v.a
>> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
>> PATTERN (B+)
>> DEFINE B AS a = 'B'
>> )
>> a | count
>> ---+-
On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
> SELECT v.a, count(*) OVER w
> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
> WINDOW w AS (
> ORDER BY v.a
> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
> PATTERN (B+)
> DEFINE B AS a = 'B'
> )
> a | count
> ---+---
> A |
Hi Vik and Champion,
I think the current RPR patch is not quite correct in handling
count(*).
(using slightly modified version of Vik's example query)
SELECT v.a, count(*) OVER w
FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
WINDOW w AS (
ORDER BY v.a
ROWS BETWEEN CURRENT ROW AND UNBOUNDED
> Thank you very much for providing the patch for the RPR implementation.
>
> After applying the v12-patches, I noticed an issue that
> the rpr related parts in window clauses were not displayed in the
> view definitions (the definition column of pg_views).
>
> To address this, I have taken the l
On Sat, 09 Dec 2023 07:22:58 +0900 (JST)
Tatsuo Ishii wrote:
> > On 04.12.23 12:40, Tatsuo Ishii wrote:
> >> diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
> >> index d631ac89a9..5a77fca17f 100644
> >> --- a/src/backend/parser/gram.y
> >> +++ b/src/backend/parser/gram.y
> >> @
> On 04.12.23 12:40, Tatsuo Ishii wrote:
>> diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
>> index d631ac89a9..5a77fca17f 100644
>> --- a/src/backend/parser/gram.y
>> +++ b/src/backend/parser/gram.y
>> @@ -251,6 +251,8 @@ static Node *makeRecursiveViewSelect(char
>> *relname, L
On 04.12.23 12:40, Tatsuo Ishii wrote:
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index d631ac89a9..5a77fca17f 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -251,6 +251,8 @@ static Node *makeRecursiveViewSelect(char *relname, List
*aliases, Nod
On Tue, Oct 24, 2023 at 7:49 PM Tatsuo Ishii wrote:
> I am impressed the simple NFA implementation.
Thanks!
> It would be nicer if it
> could be implemented without using recursion.
Yeah. If for some reason we end up going with a bespoke
implementation, I assume we'd just convert the algorithm
> Great. I will look into this.
I am impressed the simple NFA implementation. It would be nicer if it
could be implemented without using recursion.
> By the way, I tested my patch (v10) to handle more large data set and
> tried to following query with pgbench database. On my laptop it works
> wi
> On Sat, Oct 21, 2023 at 7:39 PM Tatsuo Ishii wrote:
>> Attached is the v10 patch. This version enhances the performance of
>> pattern matching.
>
> Nice! I've attached a couple of more stressful tests (window
> partitions of 1000 rows each). Beware that the second one runs my
> desktop out of m
ation and grouping
will ratchet up the complexity.
Thanks!
--Jacob
From fb3cbb6f99f0fe7b05027759454d7e0013225929 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 20 Oct 2023 16:11:14 -0700
Subject: [PATCH 2/2] squash! Row pattern recognition patch (executor).
- Extract pattern ma
suo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From a8b41dd155a2d9ce969083fcfc53bbae3c28b263 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Sun, 22 Oct 2023 11:22:10 +0900
Subject: [PATCH v10 1/7] Row pattern recognition patch for raw parser.
-
_slots. It did not correctly detect the end of full frame.
- Add test case using "ROWS BETWEEN CURRENT ROW AND offset FOLLOWING".
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From d8fd143ab717fd62814e73fd24bf1a1694
not search all possible
cases. I believe the bug is fixed in v8.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From 281ee5c3eae85f96783422cb2f9987c3af8c8a68 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Mon, 25 Sep 2023 14:01:
On Fri, Sep 22, 2023, 3:13 AM Tatsuo Ishii wrote:
> > Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
> >>> Attached is the fix against v6 patch. I will include this in upcoming
> >>> v7 patch.
> >> Attached is the v7 patch. It includes the fix mentioned above. Also
> > (Champion's address bounced; re
Op 9/22/23 om 12:12 schreef Tatsuo Ishii:
Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
Attached is the fix against v6 patch. I will include this in upcoming
v7 patch.
Attached is the v7 patch. It includes the fix mentioned above. Also
(Champion's address bounced; removed)
On my side his adress
> Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
>>> Attached is the fix against v6 patch. I will include this in upcoming
>>> v7 patch.
>> Attached is the v7 patch. It includes the fix mentioned above. Also
> (Champion's address bounced; removed)
On my side his adress bounced too:-<
> Hi,
>
> In my
Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
Attached is the fix against v6 patch. I will include this in upcoming v7 patch.
Attached is the v7 patch. It includes the fix mentioned above. Also
Hi,
In my hands, make check fails on the rpr test; see attached .diff file.
In these two statements:
Op 9/22/23 om 10:23 schreef Erik Rijkers:
Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
Attached is the fix against v6 patch. I will include this in upcoming
v7 patch.
Attached is the v7 patch. It includes the fix mentioned above. Also
(Champion's address bounced; removed)
Sorry, I forgot to
Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
Attached is the fix against v6 patch. I will include this in upcoming v7 patch.
Attached is the v7 patch. It includes the fix mentioned above. Also
(Champion's address bounced; removed)
Hi,
In my hands, make check fails on the rpr test; see attached
>From 4d5be4c27ae5e4a50924520574e2c1ca3e398551 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Fri, 22 Sep 2023 13:53:35 +0900
Subject: [PATCH v7 1/7] Row pattern recognition patch for raw parser.
---
src/backend/parser/gram.y | 222 ++--
src/include/nodes/parsenodes
> On 9/13/23 07:14, Tatsuo Ishii wrote:
>>>
>> I was looking for this but I only found ISO/IEC 19075-5:2021.
>> https://www.iso.org/standard/78936.html
>> Maybe 19075-5:2021 is the latest one?
>
> Yes, probably. Sorry.
No problem. Thanks for confirmation.
Best reagards,
--
Tatsuo Ishii
SRA OSS
On 9/13/23 07:14, Tatsuo Ishii wrote:
I was looking for this but I only found ISO/IEC 19075-5:2021.
https://www.iso.org/standard/78936.html
Maybe 19075-5:2021 is the latest one?
Yes, probably. Sorry.
--
Vik Fearing
>
I was looking for this but I only found ISO/IEC 19075-5:2021.
https://www.iso.org/standard/78936.html
Maybe 19075-5:2021 is the latest one?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
On Mon, Sep 11, 2023 at 11:18 PM Tatsuo Ishii wrote:
> What I am not sure about is, you and Vik mentioned that the
> traditional NFA is superior that POSIX NFA in terms of performance.
> But how "lexicographic ordering" is related to performance?
I think they're only tangentially related. POSIX N
Regarding v6 patch:
> SELECT company, tdate, price,
> first_value(price) OVER w,
> last_value(price) OVER w,
> max(price) OVER w,
> min(price) OVER w,
> sum(price) OVER w,
> avg(price) OVER w,
> count(price) OVER w
> FROM stock
> WINDOW w AS (
> PARTITION BY company
> ROWS BETWEEN CURRENT R
|
company2 | 07-10-2023 | 1300 | || | | |
|
(20 rows)
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From c5699cd
On Sat, Sep 9, 2023 at 4:21 AM Tatsuo Ishii wrote:
> Then we will get for str_set:
> r0: B
> r1: AB
>
> Because r0 only has classifier B, r1 can have A and B. Problem is,
> r2. If we choose A at r1, then r2 = B. But if we choose B at t1, then
> r2 = AB. I guess this is the issue you pointed out.
On 9/9/23 13:21, Tatsuo Ishii wrote:
Thanks for the explanation. Surprising concet of the standard:-)
This leaves the choice between traditional NFA and Posix NFA. The
difference between these is that a traditional NFA exits (declares a
match) as soon as it finds the first possible match,
Hi,
>> But:
>>
>> UP AS price > PREV(price)
>>
>> also depends on previous row, no?
>
> PREV(CLASSIFIER()) depends not on the value of the previous row but the
> state of the match so far. To take an example from the patch:
>
>> * Example:
>> * str_set[0] = "AB";
>> * str_set[1] = "AC";
>> * I
On 9/8/23 21:27, Jacob Champion wrote:
On 9/7/23 20:54, Tatsuo Ishii wrote:
But it's easy
to come up with a pattern where that's the wrong order, like
PATTERN ( A+ (B|A)+ )
Now "aaa" will be considered before "aab", which isn't correct.
Can you explain a little bit more? I think 'aaa'
On 9/7/23 20:54, Tatsuo Ishii wrote:
>> DEFINE
>> A AS PREV(CLASSIFIER()) IS DISTINCT FROM 'A',
>> ...
>
> But:
>
> UP AS price > PREV(price)
>
> also depends on previous row, no?
PREV(CLASSIFIER()) depends not on the value of the previous row but the
state of the match so far.
Hi,
> Hello!
>
>> (1) I completely changed the pattern matching engine so that it
>> performs backtracking. Now the engine evaluates all pattern elements
>> defined in PATTER against each row, saving matched pattern variables
>> in a string per row. For example if the pattern element A and B
>> e
Hello!
> (1) I completely changed the pattern matching engine so that it
> performs backtracking. Now the engine evaluates all pattern elements
> defined in PATTER against each row, saving matched pattern variables
> in a string per row. For example if the pattern element A and B
> evaluated to tr
he server terminated abnormally
> before or while processing the request.
> connection to server was lost
Thank you for the report. Currently the patch has an issue with
aggregate functions including max. I have been working on aggregations
in row pattern recognition but will take mo
Op 9/2/23 om 08:52 schreef Tatsuo Ishii:
Attached is the v5 patch. Differences from previous patch include:
Hi,
The patches compile & tests run fine but this statement from the
documentation crashes an assert-enabled server:
SELECT company, tdate, price, max(price) OVER w FROM stock
WINDO
0] c:\cirrus\build\src\backend\parser\gram.h(379): note: see
declaration of 'PATTERN'
[10:07:57.860] ninja: build stopped: subcommand failed.
* Resolve complaint from "make headerscheck"
- Change Windowapi.h and nodeWindowAgg.c to remove unecessary exter
YWORD, BARE_LABEL)
PG_KEYWORD("strip", STRIP_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("subscription", SUBSCRIPTION, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("subset", SUBSET, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("substring", SUBSTRING, COL_NAME_KEY
>>> - PATTERN variables do not have to exist in the DEFINE clause. They are
>>> - considered TRUE if not present.
>> Do you think we really need this? I found a criticism regarding this.
>> https://link.springer.com/article/10.1007/s13222-022-00404-3
>> "3.2 Explicit Definition of All Row Pattern
On 7/28/23 13:02, Tatsuo Ishii wrote:
Attached is the v3 patch. In this patch following changes are made.
- PATTERN variables do not have to exist in the DEFINE clause. They are
- considered TRUE if not present.
Do you think we really need this? I found a criticism regarding this.
https://l
>> Attached is the v3 patch. In this patch following changes are made.
>
> Excellent. Thanks!
You are welcome!
> A few quick comments:
>
> - PERMUTE is still misspelled as PREMUTE
Oops. Will fix.
> - PATTERN variables do not have to exist in the DEFINE clause. They are
> - considered TRUE i
On 7/26/23 14:21, Tatsuo Ishii wrote:
Attached is the v3 patch. In this patch following changes are made.
Excellent. Thanks!
A few quick comments:
- PERMUTE is still misspelled as PREMUTE
- PATTERN variables do not have to exist in the DEFINE clause. They are
considered TRUE if not presen
On 7/28/23 09:09, Tatsuo Ishii wrote:
We already recalculate a frame each time a row is processed even
without RPR. See ExecWindowAgg.
Yes, after each row. Not for each function.
Ok, I understand now. Closer look at the code, I realized that each
window function calls update_frameheadpos, wh
> I am going to add this thread to CommitFest and plan to add both of
> you as reviewers. Thanks in advance.
Done.
https://commitfest.postgresql.org/44/4460/
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From 16cab4e23f38b447a814773fea83a74c337a08d5 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Wed, 26 Jul 2023 19:49:09 +0900
Subject: [PATCH v3 1/7] Row pattern recognition patch for raw parser.
---
src/backend/parser/gram.y | 218
Hi,
> diff --git a/src/test/regress/expected/rpr.out
> b/src/test/regress/expected/rpr.out
> index 6bf8818911..f3fd22de2a 100644
> --- a/src/test/regress/expected/rpr.out
> +++ b/src/test/regress/expected/rpr.out
> @@ -230,6 +230,79 @@ SELECT company, tdate, price, rpr(price) OVER w FROM
> stock
On 7/24/23 02:22, Tatsuo Ishii wrote:
What we are talking about here is *defining* a window
frame.
Well, we are defining a "reduced" window frame within a (full) window
frame. A "reduced" window frame is calculated each time when a window
function is called.
Why? It should only be recalculat
>>> What we are talking about here is *defining* a window
>>> frame.
>> Well, we are defining a "reduced" window frame within a (full) window
>> frame. A "reduced" window frame is calculated each time when a window
>> function is called.
>
>
> Why? It should only be recalculated when the current
On 7/22/23 08:14, Tatsuo Ishii wrote:
On 7/22/23 03:11, Tatsuo Ishii wrote:
Maybe. Suppose a window function executes row pattern matching using
price > PREV(price). The window function already receives
WindowStatePerFuncData. If we can pass the WindowStatePerFuncData to
PREV, we could let PREV
> On 7/22/23 03:11, Tatsuo Ishii wrote:
> Maybe
> that can help clarify the design? It feels like it'll need to
> eventually
> be a "real" function that operates on the window state, even if it
> doesn't support all of the possible complexities in v1.
Unfortunately an windo
On 7/22/23 03:11, Tatsuo Ishii wrote:
Maybe
that can help clarify the design? It feels like it'll need to eventually
be a "real" function that operates on the window state, even if it
doesn't support all of the possible complexities in v1.
Unfortunately an window function can not call other wind
>> One small concern is how to convert pattern variables to regex
>> expression which our regex enginer understands. Suppose,
>>
>> PATTERN UP+
>>
>> Currently I convert "UP+" to "U+" so that it can be fed to the regexp
>> engine. In order to do that, we need to know which part of the pattern
>>
On 7/22/23 01:14, Jacob Champion wrote:
On 7/20/23 17:07, Vik Fearing wrote:
On 7/21/23 01:36, Jacob Champion wrote:
(I've attached two failing tests against v2, to hopefully better
illustrate, along with what I_think_ should be the correct results.)
Almost. You are matching 07-01-2023 but
On 7/20/23 23:16, Tatsuo Ishii wrote:
> I don't know at this point. I think context-free is not enough to be
> repsented in Bison. The grammer also needs to be LALR(1). Moreover,
> adding the grammer to existing parser may generate shift/reduce
> errors.
Ah. It's been too long since my compilers
On 7/20/23 17:07, Vik Fearing wrote:
> On 7/21/23 01:36, Jacob Champion wrote:
>> (I've attached two failing tests against v2, to hopefully better
>> illustrate, along with what I_think_ should be the correct results.)
>
> Almost. You are matching 07-01-2023 but the condition is "price > 100".
Hi,
> Hi Ishii-san,
>
> On 7/19/23 22:15, Tatsuo Ishii wrote:
>> Currently my patch has a limitation for the sake of simple
>> implementation: a pattern like "A+" is parsed and analyzed in the raw
>> parser. This makes subsequent process much easier because the pattern
>> element variable (in thi
On 7/21/23 01:36, Jacob Champion wrote:
There's also the issue of backtracking in the face of reclassification,
as I think Vik was alluding to upthread.
We definitely need some kind of backtracking or other reclassification
method.
(I've attached two failing tests against v2, to hopefully b
Hi Ishii-san,
On 7/19/23 22:15, Tatsuo Ishii wrote:
> Currently my patch has a limitation for the sake of simple
> implementation: a pattern like "A+" is parsed and analyzed in the raw
> parser. This makes subsequent process much easier because the pattern
> element variable (in this case "A") and
> Hello,
>
> Thanks for working on this! We're interested in RPR as well, and I've
> been trying to get up to speed with the specs, to maybe make myself
> useful.
Thank you for being interested in this.
> 19075-5 discusses that, at least; not sure about other parts of the spec.
Thanks for the i
Hello,
Thanks for working on this! We're interested in RPR as well, and I've
been trying to get up to speed with the specs, to maybe make myself
useful.
On 6/27/23 17:58, Tatsuo Ishii wrote:
> Yes. (I think the standard calls the window frame as "full window
> frame" in context of RPR to make a c
On 6/28/23 14:17, Tatsuo Ishii wrote:
Small question.
This query (with all the defaults made explicit):
SELECT s.company, s.tdate, s.price,
FIRST_VALUE(s.tdate) OVER w,
LAST_VALUE(s.tdate) OVER w,
lowest OVER w
FROM stock AS s
WINDOW w AS (
PARTITION BY s.company
Small question.
> This query (with all the defaults made explicit):
>
> SELECT s.company, s.tdate, s.price,
>FIRST_VALUE(s.tdate) OVER w,
>LAST_VALUE(s.tdate) OVER w,
>lowest OVER w
> FROM stock AS s
> WINDOW w AS (
> PARTITION BY s.company
> ORDER BY s.tdate
> ROWS
> Okay, I see the problem now, and why you need the rpr() function.
>
> You are doing this as something that happens over a window frame, but
> it is actually something that *reduces* the window frame. The pattern
> matching needs to be done when the frame is calculated and not when
> any particu
On 6/26/23 03:05, Tatsuo Ishii wrote:
I don't understand this. RPR in a window specification limits the
window to the matched rows, so this looks like your rpr() function is
just the regular first_value() window function that we already have?
No, rpr() is different from first_value(). rpr() re
x_en/
Japanese:http://www.sraoss.co.jp
>From 92aebdb8a8c6d3739ee49b755f281e77c34f5d36 Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Mon, 26 Jun 2023 17:05:35 +0900
Subject: [PATCH v2 1/7] Row pattern recognition patch for raw parser.
---
src/backend/parser/gram.y | 218 +---
src/
> I have been dreaming of and lobbying for someone to pick up this
> feature. I will be sure to review it from a standards perspective and
> will try my best to help with the technical aspect, but I am not sure
> to have the qualifications for that.
>
> THANK YOU!
Thank you for looking into my p
On 6/25/23 14:05, Tatsuo Ishii wrote:
Attached is a PoC patch to implement "Row pattern recognition" (RPR)
in SQL:2016 (I know SQL:2023 is already out, but I don't have access
to it). Actually SQL:2016 defines RPR in two places[1]:
Feature R010, “Row pattern recogniti
Attached is a PoC patch to implement "Row pattern recognition" (RPR)
in SQL:2016 (I know SQL:2023 is already out, but I don't have access
to it). Actually SQL:2016 defines RPR in two places[1]:
Feature R010, “Row pattern recognition: FROM clause”
Feature R020, “Row patt
79 matches
Mail list logo
