Re: Small changes to facilitate Win32 port - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Small changes to facilitate Win32 port
Date
Msg-id 18287.1022858008@sss.pgh.pa.us
Whole thread Raw
In response to Re: Small changes to facilitate Win32 port  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.org> 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.

> "P" for "Parser".

Oh, okay.  I'm not intent on changing it, just was wondering what the
motivation was.  What do you think of changing all the token symbols to
be FOO_P?  (Or P_FOO, per your comment, but I'd just as soon leave alone
the ones that already have a suffix.)

> The symbols are used past the lexer, but are isolated
> to other places in the parser, and are (or should be) stripped out
> beyond there.

Right at the moment we have half a dozen cases where they leak past the
parser, e.g. TransactionStmt.  I've been intending to clean that up.
I concur that we don't want anything past parse analysis to depend on
token values, since they change anytime the keyword set changes.

> If the lexer/parser should have postfix qualifiers, let's use postfix
> for other naming conventions too (or switch everything to prefix, but be
> consistant in the conventions).

I'd settle for local consistency: if we need prefixes/suffixes on some
of the datetime field names, let's make all of them have one.  But I
don't feel compelled to cause a flag day over the whole source tree ;-).
At least not all at once.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Small changes to facilitate Win32 port
Next
From: Thomas Lockhart
Date:
Subject: Re: Small changes to facilitate Win32 port