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
