| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | jian(dot)universality(at)gmail(dot)com |
| Cc: | assam258(at)gmail(dot)com, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Row pattern recognition |
| Date: | 2026-05-17 10:00:23 |
| Message-ID: | 20260517.190023.159085681032648582.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Jian,
>> > Attached is the v47 patches for Row pattern recognition (SQL/RPR).
>>
>
> Hi
> The patchset is too big, I only downloaded v47-0001...
I understand your complain. Yes, the patch set is big. But that's
because the feature (SQL/RPR) is big. There's no way to avoid it. I
tried to make the patch set as small as possible, keeping the
functionality to be useful in the real world at the same time.
Fortunately Henson wrote a very usefully document:
src/backend/executor/README.rpr. It draws an outline of overall
architecture of the patch set. I strongly recommend to read it before
jumping into the code.
Another useful documents are the SQL standards. I recommend to read
ISO/IEC 19075-5. It's a 73-page document (as of 2021 edition), which
is relatively small volume comparing with other standard documents.
Currently the patch set implements PATTERN and DEFINE clauses along
with NFA regular expression engine. It lacks MEASURES clause and range
var qualified row pattern variables. If we implement these features,
it will make the patch set size even bigger. So we think that it would
be better to implement them after the initial commit of RPR. (Of
course this does not prevent the discussion of designing MEASURES
etc. for the future. We welcome it)
If you still want to add some features, there are moderately smaller
ones. For example, SEEK clause, EMPTY MATCH and subquery in the DEFINE
clause.
Thank you for interesting in RPR!
Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Just a quick skim of the code on my end.
> I noticed two code style issues, currently we don't have a code style
> reference in the manual.
>
> 1. We need to add trailing commas to enum definitions. See
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=611806cd726fc92989ac918eac48fd8d684869c7
>
> 2.
> + | '{' ',' Iconst '}' Op
> + {
> + if (strcmp($5, "?") != 0)
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("invalid token after range quantifier"),
> + errhint("Only \"?\" is allowed after {n,} or {,m} to make it reluctant."),
> + parser_errposition(@5)));
> + if ($3 <= 0 || $3 >= INT_MAX)
> + ereport(ERROR,
> + errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("quantifier bound must be between 1 and %d", INT_MAX - 1),
> + parser_errposition(@3));
> + $$ = (Node *) makeRPRQuantifier(0, $3, @5, @1, yyscanner);
>
> + (errcode(ERRCODE_SYNTAX_ERROR),
> The leading parenthesis is optional and can be removed, fewer
> parentheses are always better.
> See related discussion:
> https://postgr.es/m/202510100916.s2e6n3xiwvyc@alvherre.pgsql
>
> Since v47-0001 introduces many ereport(ERROR) messages, it makes sense
> to move the related regression tests from the other patch into
> v47-0001, IMHO.
>
>
>
> --
> jian
> https://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Dean Rasheed | 2026-05-17 09:16:39 | Re: [PATCH] Fix overflow and underflow in regr_r2() |