Thread: Scanner/Parser question - what does _P imply?
I can't find an authoritative answer to this question.<br /><br /> Many of the keywords listed in keywords.c are definedwith symbolic names that end in '_P' (underscore P).<br /><br /> What differentiates those keywords from the otherkeywords? What does the 'P' stand for?<br /><br /> Are those PostgreSQL-specific keywords (i.e. keywords not definedby the SQL standard)?<br /><br /> Thanks.<br /><br /><br /> -- Korry<br /><table cellpadding="0" cellspacing="0"width="100%"><tr><td><br /><br /> --<br /> Korry Douglas <a href="mailto:korryd@enterprisedb.com">korryd@enterprisedb.com</a><br/> EnterpriseDB <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></td></tr></table>
<korryd@enterprisedb.com> writes:
> Many of the keywords listed in keywords.c are defined with symbolic
> names that end in '_P' (underscore P).
> What differentiates those keywords from the other keywords? What does
> the 'P' stand for?
P = Parser. The reason for the _P is just to avoid conflicts with
other definitions of the macro name, either in our own code or various
platforms' header files. We haven't been totally consistent about it,
but roughly speaking we've stuck _P on when it was either known or
seemed likely that there might be a conflict.
Some years ago there was discussion of consistently P-ifying *all* those
macros, but it didn't get done; I think Thomas or somebody objected that
it would make gram.y needlessly harder to read.
regards, tom lane
<blockquote type="CITE"><pre> <font color="#000000">P = Parser. The reason for the _P is just to avoid conflicts with</font> <font color="#000000">other definitions of the macro name, either in our own code or various</font> <font color="#000000">platforms' header files. We haven't been totally consistent about it,</font> <font color="#000000">but roughly speaking we've stuck _P on when it was either known or</font> <font color="#000000">seemed likely that there might be a conflict.</font> <font color="#000000">Some years ago there was discussion of consistently P-ifying *all* those</font> <font color="#000000">macros, but it didn't get done; I think Thomas or somebody objected that</font> <font color="#000000">it would make gram.y needlessly harder to read.</font> </pre></blockquote><br /> Ahhh... now it's clear. <br /><br /> Thanks.<br /><br /><br /> -- Korry
On 1/18/2007 10:35 AM, Tom Lane wrote: > <korryd@enterprisedb.com> writes: >> Many of the keywords listed in keywords.c are defined with symbolic >> names that end in '_P' (underscore P). >> What differentiates those keywords from the other keywords? What does >> the 'P' stand for? > > P = Parser. The reason for the _P is just to avoid conflicts with > other definitions of the macro name, either in our own code or various > platforms' header files. We haven't been totally consistent about it, > but roughly speaking we've stuck _P on when it was either known or > seemed likely that there might be a conflict. > > Some years ago there was discussion of consistently P-ifying *all* those > macros, but it didn't get done; I think Thomas or somebody objected that > it would make gram.y needlessly harder to read. Are there many people who read gram.y on a regular base? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
<blockquote type="CITE"><pre> <font color="#000000">> Some years ago there was discussion of consistently P-ifying *all* those</font> <font color="#000000">> macros, but it didn't get done; I think Thomas or somebody objected that</font> <font color="#000000">> it would make gram.y needlessly harder to read.</font> <font color="#000000">Are there many people who read gram.y on a regular base?</font> </pre></blockquote><br /> I can't seem to put it down :-)<br /><br /> >From the back cover:<br /><blockquote> A rollercoasterride of passion, heart-stopping adventures, and gut-wrenching laughs ... every bit as thrilling as copyfuncs.c,more of a tearjerker than bufmgr.c, and as deliciously naughty as MySQL's item.cc. <br /></blockquote><br />Get <i><b>gram.y</b></i>, in stores now (or order at Amazon.com, delivered in a plain brown wrapper).<br /><br /><br /> -- Korry