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
