Re: Row pattern recognition

Hi Henson,

> As promised, here is a summary of the open items and my proposed
> plan for the remaining work.

> 1. FIXME bugs (to fix within the patch)
> 2. Test and documentation (within the patch)
> 3. Performance optimizations (separate follow-up patches)

1-3 look good.

> 4. Unimplemented features
>
> The following R020 features are listed in the commit message as not
> yet implemented. Could you let me know which ones you'd like to
> include in this patch versus deferring to follow-up patches?
>
> Requires per-match state tracking infrastructure:
> - MEASURE -- new clause, pattern variable references in target list,
> and per-match aggregate evaluation within the NFA executor
> - CLASSIFIER -- requires per-row variable binding in match state;
> the altPriority fix in section 1 would provide part of this
> infrastructure

I thought we can defere these after the first committed version. I
think these are too large to add the current patch sets.

> Quantifier/pattern extensions:
> - Reluctant quantifiers (*? etc.) -- parsing exists, runtime error

Reluctant quantifiers seem to have important usecases (i.e. the
shortest path). But if implementation is too difficult, we should
defer to after the first version.

> - {- -} (exclusion)
> - Empty pattern -- A{0}, () empty pattern. Should we implement
> A{0} in this patch and defer empty match semantics (unmatch vs
> empty match distinction) to when MEASURE is implemented?

Yes, I think so. We should defer.

> A{0,0}: standard forbids, Oracle/Snowflake allow.
> Should we follow the standard and reject A{0,0}?

I think we should follow the standard.

> - PERMUTE -- can be expanded to alternations at parse time

I though we could defer after the first commit. Do you wish to
implemenet it now?

> Navigation/control:
> - SEEK
> - AFTER MATCH SKIP TO / FIRST / LAST
> (only SKIP PAST LAST ROW and SKIP TO NEXT ROW are supported)

Let's defer them.

> Row pattern functions:
> - SUBSET -- variable grouping for aggregate evaluation
> - FIRST, LAST

Let's defer them.

> Out of scope:
> - MATCH_RECOGNIZE (R010)
>
>
> I'd like your thoughts on the following scope questions:
> - Reluctant quantifiers: in scope for this patch?

I found reluctant quantifiers are useful but also I don't want to make
patch sets far bigger. How do yo estimate the difficulty and the size
of the code for reluctant quantifiers?

> - A{0}: proceed with implementation?
> - () empty pattern: also in scope, or defer?

I think we can defer.

> - A{0,0}: reject per standard, or allow like Oracle/Snowflake?

Let's reject per standard.

> There are quite a few items listed above, and I'd like to
> make sure I'm working on the right things in the right order.
> If you could give me some guidance on which items to prioritize
> and how you'd like to see these addressed, that would be very
> helpful.

Here are my thoughts. What do you think?

BTW, while researching the standard, I am wondering whether empty
DEFINE clause is allowed (DEFINE without any variable definition at
all). According to ISO/IEC 9075-2:

<row pattern definition list> ::=
<row pattern definition> [ { <comma> <row pattern definition> }...]

<row pattern definition> ::=
<row pattern definition variable name> AS < row pattern definition search condition>
:
:

So, it seems a bare DEFINE clause is not allowed. However searching
goole, it says that the standard allow a bare DEFINE. Maybe it's a
hallucination?
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp