Re: Row pattern recognition

From: Henson Choi <assam258(at)gmail(dot)com>
To: shinsj4653(at)gmail(dot)com, Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: jian(dot)universality(at)gmail(dot)com, vik(at)postgresfriends(dot)org, pgsql-hackers(at)postgresql(dot)org, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, 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, li(dot)evan(dot)chao(at)gmail(dot)com
Subject: Re: Row pattern recognition
Date: 2026-07-19 10:54:30
Message-ID: CAAAe_zD=6RGs91imQOn=oP7wq+iNJ86q4O-T5=8Pco36Jkkk8A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Seongjun, Tatsuo,

I reproduced this here as well, on two platforms:

- macOS / Apple Silicon, GNU Bison 2.3 (the system bison, and the
tree's declared minimum): gram.h carries "#define INITIAL 472"
next to the enum, so it collides with flex's "#define INITIAL 0"
-- the two -Wmacro-redefined warnings (backend scan.c, ecpg
pgc.c) both appear.
- Rocky Linux 10.1, GNU Bison 3.8.2 (a different distro from
Tatsuo's Ubuntu, but the same bison): gram.h has only the enum,
no "#define INITIAL", and the build is clean.

So it is purely the bison version, as you and Tatsuo concluded. In
fact I had -Wno-macro-redefined in my build flags because of a compile
issue with some extensions, which masked this warning so I hadn't
noticed it -- thanks for flagging it. Without that flag (a stock
./configure build, or meson), bison 2.3 shows it.

> 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.

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.

Best regards,
Henson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Masterov 2026-07-19 12:16:47 Re: Unexpected behavior after OOM errors
Previous Message Tatsuo Ishii 2026-07-19 09:43:05 Re: Row pattern recognition