Hi Henson,
>> Your patch looks good to me except "INITIALLY" should be before
>> "INITIAL_P" in ASCII. ('L' == 0x4c, '_' == 0x5f in ASCII).
>
> I think the ordering is already right as the patch has it. The
> keyword lists sort every _P symbol as if the suffix weren't there,
> i.e. by its bare name. In the %token block alone, these adjacent
> pairs all place an X_P ahead of a word that raw ASCII would sort
> first:
>
> CHAR_P/CHARACTER, CURRENT_P/CURRENT_CATALOG, DATA_P/DATABASE,
> GROUP_P/GROUPING, IN_P/INCLUDE, INT_P/INTEGER, LOCK_P/LOCKED,
> NAME_P/NAMES, NULL_P/NULLIF, OBJECT_P/OBJECTS_P, OUT_P/OUTER_P,
> REF_P/REFERENCES, TYPE_P/TYPES_P, VALUE_P/VALUES,
> XML_P/XMLATTRIBUTES
>
> INITIAL_P before INITIALLY is the same pattern (INITIAL < INITIALLY).
> This is exactly what check_keywords.pl enforces -- it strips the _P
> before the comparison -- so the patch passes as-is, while swapping to
> INITIALLY first fails with
>
> 'INITIAL' after 'INITIALLY' in bare_label_keyword list is misplaced
>
> and exits non-zero, which would break the build.
Oh, I didn't know that. You are right.
BTW, I noticed a comment in gram.y:
* We need to do this for PARTITION, RANGE, ROWS, GROUPS, AFTER, INITIAL,
* SEEK, PATTERN_P to support opt_existing_window_name (see comment there).
Even if we change INITIAL to INITIAL_P, we should not change the
comment. Moreover, PATTERN_P (which was added by RPR patch too) in
the comment above should have been PATTERN. Because we are talking
about SQL keywords, not bison tokens.
> So I don't think any reordering is needed. I'll carry the patch as
> nocfbot-0002 in the 0XXX (base build adjustment) band of the next
> incremental posting, so the series stays coherent until it is folded
> into the raw-parser patch.
Thanks.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
