Skip site navigation (1) Skip section navigation (2)

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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Date: 2000-02-28 23:19:22
Message-ID: Pine.LNX.4.21.0002290000170.3511-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: 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(at)gmx(dot)net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-02-28 23:19:57
Subject: Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
Previous:From: Peter EisentrautDate: 2000-02-28 23:19:05
Subject: Re: [SQL] prob with aggregate and group by - returns multiples

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group