Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> Another is that depending on where you put the renaming that this patch
>> removes without replacing :-(,
> I do not understand your point. It seems to me that the renaming is
> performed when a type name is expected? The "boolean" keyword (not token)
> is translated to system "bool" type in the GenericType rule?? ???
I mean that you removed functionality without putting it back; the
modified parser will fail to recognize BOOLEAN as a type name at all,
because it doesn't match "bool" which is in the catalogs. (And changing
the entry to "boolean" is not a solution, it just moves the problem.)
I assume you intended to handle this by doing the substitutions in type
name lookup elsewhere in the parser, but I don't think that is a valid
solution, because there is no longer enough information. In particular
you can't any longer tell the difference between BOOLEAN and "boolean"
(with quotes), which are not the same thing --- a quoted string is never
a keyword, per spec.
Possibly a better example than boolean is the REAL => pg_catalog.float4
transformation. If a user has defined his own type named foo.real,
he ought to be able to refer to it as "real" (with quotes) and not get
messed up by the keyword transformation. I think our original
motivation for converting all these things to keywords was the
realization that pg_dump would in fact screw up and fail to dump such
a type definition correctly if "real" wasn't recognized as conflicting
with a keyword (which is what prompts pg_dump to stick quotes on).
The basic point here is that eliminating tokens as you propose will
result in small changes in behavior, none of which are good or per spec.
Making the parser automaton smaller would be nice, but not at that
price.
> My point is that you can have the very same *semantical* result with a
> smaller automaton if you chose a different trade-off within the
> lexer/parser/post filtering. I don't want to change the language.
You have not proven that you can have the same result.
regards, tom lane
