> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Thursday, May 30, 2002 3:25 PM
> To: Christopher Kings-Lynne
> Cc: Katherine Ward; Thomas Lockhart; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Small changes to facilitate Win32 port 
> 
> 
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > It's more likely that your changes will go through if you 
> just submit a
> > patch!
> 
> I think the question was more directed at "do we like these names?",
> which should certainly be asked before going to the trouble 
> of making a
> patch.
> 
> >> 2.  Add _P to the following lex/yacc tokens to avoid collisions
> >> CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT
> 
> I'm tempted to suggest that we should stick _P on *all* the 
> lexer token
> symbols, rather than having an inconsistent set of names where some of
> them have _P and some do not.  Or perhaps _T (for token) 
> would be a more
> sensible convention; I'm not sure why _P was used in the first place.

Before you do that, realize that you are violating the implementation's
namespace, and your code is therefore not legal ANSI/ISO C.

From ISO/IEC 9899:1999 (E) ©ISO/IEC:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its
associated subclause, and
optionally declares or defines identifiers listed in its associated
future library directions
subclause and identifiers which are always reserved either for any use
or for use as file
scope identifiers.
- All identifiers that begin with an underscore and either an uppercase
letter or another
underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for
use as identifiers
with file scope in both the ordinary and tag name spaces.
- Each macro name in any of the following subclauses (including the
future library
directions) is reserved for use as specified if any of its associated
headers is included;
unless explicitly stated otherwise (see 7.1.4).
- All identifiers with external linkage in any of the following
subclauses (including the
future library directions) are always reserved for use as identifiers
with external
linkage.154)
- Each identifier with file scope listed in any of the following
subclauses (including the
future library directions) is reserved for use as a macro name and as an
identifier with
file scope in the same name space if any of its associated headers is
included.
 
> >> 3.  Rename two local macros
> >> a.  MEM_FREE => MEM_FREE_IT in backend/utils/hash/dynahash.c
> >> b.  IGNORE => IGNORE_TOK in include/utils/datetime.h &
> >> backend/utils/adt/datetime.c
> 
> It's fairly amazing that IGNORE is the only one of the 
> datetime.h field
> names that's bitten anyone (so far).  Macros named TZ, YEAR, 
> MONTH, DAY,
> HOUR, MINUTE, SECOND, UNITS all look like trouble waiting to happen
> (and UNKNOWN_FIELD looks like someone already had to beat a 
> retreat from
> calling it UNKNOWN ;-)).  I'm inclined to suggest that these names
> should be uniformly changed to DTF_FOO (DTF for "datetime field").
> The macro names appearing before the field name list look like trouble
> as well --- anyone have an interest in changing them?  Thomas, this is
> pretty much your turf; what do you think?
> 
> 			regards, tom lane
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

Thu, 30 May 2002 15:34:39 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Small changes to facilitate Win32 port 
"Dann Corbit" <DCorbit@connx.com> writes:
>> I'm tempted to suggest that we should stick _P on *all* the 
>> lexer token
>> symbols, rather than having an inconsistent set of names where some of
>> them have _P and some do not.  Or perhaps _T (for token) 
>> would be a more
>> sensible convention; I'm not sure why _P was used in the first place.

> Before you do that, realize that you are violating the implementation's
> namespace, and your code is therefore not legal ANSI/ISO C.

What?

The _P or _T is a suffix, not a prefix...

			regards, tom lane

Thu, 30 May 2002 18:40:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Small changes to facilitate Win32 port 