Re: Row pattern recognition

Hi Henson,

>> Excellnt findings!  BTW, I realized that we cannot use $1 of function
>> in PATTERN clause like: A{$1}.
>>
>> ERROR:  42601: syntax error at or near "$1"
>> LINE 10:         PATTERN (A{$1})
>>                             ^
>> LOCATION:  scanner_yyerror, scan.l:1211
>>
>> Should we document somewhere?
>>
> 
> The PATTERN quantifier {n} only accepts Iconst (integer literal) in the
> grammar.  When a host variable or function parameter is used (e.g.,
> A{$1}), the user gets a generic syntax error.

Ok.

> Oracle accepts broader syntax and validates later, producing an error
> at a later stage rather than a syntax error at parse time.
> 
> PostgreSQL itself already has precedent for this pattern -- in fact,
> within the same window clause, frame offset (ROWS/RANGE/GROUPS) accepts
> a_expr in the grammar and then rejects variables in parse analysis via
> transformFrameOffset() -> checkExprIsVarFree().
> 
> I'd lean against documenting this.  The SQL standard already defines
> the quantifier bound as <unsigned integer literal>, so there is nothing
> beyond the standard to call out, and documenting what is *not* allowed
> tends to raise questions that wouldn't otherwise occur to users.
> 
> Rather, I think accepting a broader grammar and validating later would
> be the more appropriate response, producing a descriptive error like:
> 
>   "argument of bounded quantifier must be an integer literal"
> 
> I can either include this in the current patch set or handle it as a
> separate follow-up after the main series is committed.  What do you
> think?

I think handing it as a separate follow-up after the commit is enough
unless other developers complain.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp