Thread: Keywords
Could anyone tell me why a term like 'int' is not a keyword? Also I need a list of postgresql types so I know which ones should be accepted by ecpg. Finally I wonder whether we should make all ecpg keywords keywords for the backend too. Or else we could end up with queries expressable via psql but not via ecpg. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
> Could anyone tell me why a term like 'int' is not a keyword? > > Also I need a list of postgresql types so I know which ones should be > accepted by ecpg. We don't reserve the type names as keywords, and because they can create their own types, it wouldn't make sense. > > Finally I wonder whether we should make all ecpg keywords keywords for the > backend too. Or else we could end up with queries expressable via psql but > not via ecpg. Seems like more work than it's worth, no? Why not have psql queries that can't be done in ecpg. Most commercial embedded sql's have a more limited keyword set, don't they? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Could anyone tell me why a term like 'int' is not a keyword?
What Bruce sez...
> Also I need a list of postgresql types so I know which ones should be
> accepted by ecpg.
Check the chapter on data types in the new html/hardcopy User's Guide.
But since you can define new types, I'm not sure whatever you are
planning is general enough. The main parser gram.y has to support
several different kinds of type syntax, for SQL92 date/time (e.g. TIME
WITH TIME ZONE), character strings (e.g. CHARACTER VARYING, numeric
types (e.g. FLOAT(6)) and others (e.g. INTEGER).
> Finally I wonder whether we should make all ecpg keywords keywords for
> the backend too. Or else we could end up with queries expressable via
> psql but not via ecpg.
Not out of the question. We could then share keywords.c between the two
interfaces.
- Tom
On Mon, Feb 08, 1999 at 01:15:09PM -0500, Bruce Momjian wrote: > We don't reserve the type names as keywords, and because they can create > their own types, it wouldn't make sense. I don't exactly understand that. For instance the 'int' keyword will still be reserved, isn't it? > Seems like more work than it's worth, no? Why not have psql queries > that can't be done in ecpg. Most commercial embedded sql's have a more > limited keyword set, don't they? I have no idea. Anyone else? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
Michael Meskes wrote: > > On Mon, Feb 08, 1999 at 01:15:09PM -0500, Bruce Momjian wrote: > > We don't reserve the type names as keywords, and because they can create > > their own types, it wouldn't make sense. > > I don't exactly understand that. For instance the 'int' keyword will still > be reserved, isn't it? > Just tested: hannu=> create table int(int int); CREATE Though: hannu=> create table int4(int4 int4); ERROR: TypeCreate: type int4 already defined So it's probably not reserved ;) -------------- Hannu
Hannu Krosing wrote:
>
> Michael Meskes wrote:
> >
> > On Mon, Feb 08, 1999 at 01:15:09PM -0500, Bruce Momjian wrote:
> > > We don't reserve the type names as keywords, and because they can
> > > create their own types, it wouldn't make sense.
> > I don't exactly understand that. For instance the 'int' keyword will
> > still be reserved, isn't it?
> hannu=> create table int(int int);
> CREATE
> hannu=> create table int4(int4 int4);
> ERROR: TypeCreate: type int4 already defined
> So it's probably not reserved ;)
INT is an SQL92 reserved word. But it is not a reserved word in
Postgres, since the usage as a reserved word would be exclusively as a
type name. In Postgres, the parser does not require a type name to be
explicitly defined as a keyword (which would make it a de facto reserved
word) since we allow type extensibility. Parsing it explicitly as a
keyword does not buy us any new functionality (since we allow type names
which are definitely *not* keywords anyway), so we don't do it.
However, it is handled in a special way: in contexts where one would
expect a type name, "int" is translated to "int4" explicitly (very early
on, from gram.y). Otherwise it is not translated.
- Tom
On Wed, Feb 10, 1999 at 02:28:10AM +0000, Thomas G. Lockhart wrote: > However, it is handled in a special way: in contexts where one would > expect a type name, "int" is translated to "int4" explicitly (very early > on, from gram.y). Otherwise it is not translated. And int4 is reserved? Is is not in keywords.c though. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
> > However, it is handled in a special way: in contexts where one would
> > expect a type name, "int" is translated to "int4" explicitly (very
> > early on, from gram.y). Otherwise it is not translated.
> And int4 is reserved? Is is not in keywords.c though.
No! That's the point, really; there are very few keywords which are type
names. afaik the only cases where type names show up as keywords are
where SQL92 syntax requires special handling, such as "TIMESTAMP WITH
TIME ZONE" and "NATIONAL CHARACTER VARYING". And even in those cases
I've tried to allow as broad a usage as possible, so even though
something is a keyword it may be allowed as a column name, type name, or
identifier unless prohibited by the yacc one-token-lookahead
limitations.
Look in the hardcopy or html User's Guide for the chapter on "Syntax",
which lists the SQL92 and Postgres reserved words. I neglected to add
that chapter to the "integrated docs" (postgres.html) in the last
release, so you will need to look at user.html to find it. Also, it
doesn't include recent changes from Vadim et al for MVCC, which I expect
will add a few keywords eventually.
- Tom
Michael Meskes wrote: > > On Wed, Feb 10, 1999 at 02:28:10AM +0000, Thomas G. Lockhart wrote: > > However, it is handled in a special way: in contexts where one would > > expect a type name, "int" is translated to "int4" explicitly (very early > > on, from gram.y). Otherwise it is not translated. > > And int4 is reserved? Is is not in keywords.c though. No it's not, it just happens that it is already defined as a type, and in postgres defining a table also defines a type. In some senses table and type in postgres mean the same thing. ---------------------- Hannu
On Wed, Feb 10, 1999 at 03:11:38PM +0000, Thomas G. Lockhart wrote: > No! That's the point, really; there are very few keywords which are type > names. afaik the only cases where type names show up as keywords are I see. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!