Tom Lane writes:
> > I'm not sure that I agree that multi-word character types are required
> > internally. Somehow that seems to just push the problem of
> > SQL92-specific syntax to another part of the code.
>
> It doesn't push it anywhere: you still have the problem that the parser
> expects type names to be single tokens, not multiple tokens, and any
> exceptions need to be special-cased in the grammar. We can handle that
> for the few multi-word type names decreed by SQL92. But allowing
> internal type names to be multi-word as well will create more headaches
> in other places (even if it doesn't make the grammar ambiguous, which
> it well might). I think the bootstrap scanner would just be the tip of
> the iceberg...
I don't get that. What's wrong with (conceptually) having a rule like
this:
Type: TIME { $$ = "time"; } | REAL { $$ = "real"; } | CHAR { $$ = "char"; } | BIT VARYING { $$ = "bit varying"; }
| Id { $$ = $1; } /* potentially user-defined type */
This is pretty much what it does now, only that the right side of $$ =
"..." never contains a space, which is purely coincidental.
The list of multi-token SQL types is very finite. Any user-defined
types with spaces would have to use the usual double-quote mechanism. The
advantage of the above is that once I have "bit varying" in the catalog, I
don't have to worry mangling it when I want to get it out.
I don't understand where you get the notion of "multiworded internal
types" from. All that would be required is concatenating a set of specific
token combinations to one and you're done. Once that is done, no one
worries about the fact that there is in fact a space in the type name.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden