Re: Row pattern recognition

Hi Jian,

> PATTERN (A B C | B)
> can be interpreted as
> PATTERN (A B (C | B))
> or
> PATTERN ((A B C) | B)
>
> We need extra parentheses to disambiguate it.

I don't think it is ambiguous. In the standard grammar an
alternation is made of terms, and a term is a concatenation of
factors, so concatenation binds tighter than alternation. It is
the same as in regular expressions, and as a product before a sum
in a * b * c + b. Our gram.y has the same structure
(row_pattern_alt '|' row_pattern_seq), so A B C | B can only be
read as ((A B C) | B), and the \sv output reads back as the same
pattern.

Both printers rely on this precedence. pg_get_viewdef() prints
only the parentheses the user wrote, and EXPLAIN brackets each
alternation but not a sequence branch inside it. Anyone who reads
regular expressions knows this precedence, so I think the current
compact form is better than spelling out every level with
parentheses.

> PATTERN (A B ?c)
> is interpreted as
> PATTERN (A B? c)
>
> Maybe one para in select.sgml is enough to explain this

This is the standard reading too. The lexer drops whitespace, so
B? C, B ? C and B ?C give the same tokens, and a quantifier applies
to the element just before it. Whitespace means nothing in a
pattern except to separate pattern variables, as elsewhere in SQL.
Spacing that invites a misreading is up to whoever writes the
pattern, so I don't think it needs a paragraph of its own.

> While looking at it, i think the below paragraph is not necessary.

That paragraph was added because Tatsuo asked on September 20 to
list those two restrictions, to be fair to people evaluating and
reviewing the RPR patches. For that purpose there may be a better
place than the manual. The patch is large, so once the public
review gets going, reviewers will need a guide, and I think it
would be better to collect restrictions like these there, in the
form of an audit report. The paragraph could then come out of the
manual. Tatsuo, what do you think?

Best regards,
Henson