Thomas Lockhart <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
