Re: [HACKERS] Beta for 4:30AST ... ?
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Beta for 4:30AST ... ? |
Дата | |
Msg-id | Pine.LNX.4.21.0002290000170.3511-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [HACKERS] Beta for 4:30AST ... ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: