From: Henson Choi <assam258(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: 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,
pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Hi Tatsuo,
Thanks for the feedback! Here are my responses to your questions.
> 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.
>
> How do you estimate the difficulty and the size of the code for
> reluctant quantifiers?
The core difficulty is not in nfa_advance() itself but in matched
state replacement: once a greedy match is confirmed, replacing it
with a shorter reluctant match requires updating matchedState, which
the current structure does not support cleanly.
This is the same design gap that underlies the altPriority FIXME:
both problems require rethinking how the confirmed match state
interacts with the active NFA state list. I think it is worth
solving them together.
I would prefer to work on the altPriority redesign first and include
reluctant quantifiers and state pruning as part of that work if the
design allows it cleanly.
If I encounter design issues that are difficult to resolve, I will
come back to discuss before proceeding.
> > - {- -} (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}: proceed with implementation?
> > - () empty pattern: also in scope, or defer?
>
> I think we can defer.
Just to confirm: my understanding is that A{0} is in scope for this
patch, while () empty pattern and empty match semantics are deferred.
Is that correct? If so, I plan to implement A{0} together with the
cycle detection fix for patterns like (A*)*, since both involve
zero-length iteration handling.
> I though we could defer after the first commit. Do you wish to
> implement it now?
> [regarding PERMUTE]
I am happy to defer PERMUTE.
> 1-3 look good.
I will address test reorganization and documentation review after the bug
fixes and feature implementations are complete.
> BTW, while researching the standard, I am wondering whether empty
> DEFINE clause is allowed (DEFINE without any variable definition at
> all). [...] So, it seems a bare DEFINE clause is not allowed.
> However searching google, it says that the standard allow a bare
> DEFINE. Maybe it's a hallucination?
That seems right. DEFINE with no definitions is not allowed; the
parser rejects it syntactically.
On a related note: since the standard treats variables not listed in
DEFINE as implicitly TRUE, should we allow PATTERN without DEFINE?
Best regards,
Henson
