Re: [HACKERS] Beta for 4:30AST ... ?

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