Re: [HACKERS] AUTO_INCREMENT suggestion

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Mattias Kregert <matti(at)algonet(dot)se>
Cc: "D(dot) Dante Lorenso" <dlorenso(at)afai(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] AUTO_INCREMENT suggestion
Date: 1998-03-06 14:03:40
Message-ID: 3500023C.4E7FDB44@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > To aid those of us that don't want to use sequences

?? What is our next feature?

"To aid those who don't want to use Postgres..."

Sorry, couldn't resist ;-)

> , can we add a
> > feature to 6.4 that allows the use of an AUTO_INCREMENT statement
> > when defining tables? MySQL does this, and I like it. It resembles
> > the Autonumber feature in Access as well.
> >
> > create table tblFirm (
> > FirmID int PRIMARY KEY AUTO_INCREMENT,
> > FirmTypeID int,
> > FirmName varchar(64) NOT NULL,
> > FirmAlpha char(20) NOT NULL UNIQUE,
> > FirmURL varchar(64),
> > FirmEmail varchar(64)
> > );
>
> Since the PRIMARY KEY is implemented by creating an unique index
> on the field, it should be easy to implement AUTO_INCREMENT by
> automagically creating a sequence and setting it as the default for
> this field.
>
> Was PRIMARY KEY implemented in the parser?

Yes, in gram.y and then is transformed into essentially a
CREATE UNIQUE INDEX statement afterwards, still in the parser-related
code. This kind of change is ugly, since it has side effects (an index is
created with a specific name which might conflict with an existing name),
but was done for SQL92 compatibility. I'd be less than excited about
doing ugly code with side effects (a sequence is created, etc) for
compatibility with a specific commercial database.

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Hartwig 1998-03-06 14:33:08 Re: [HACKERS] Speedups
Previous Message The Hermit Hacker 1998-03-06 13:33:25 Re: [HACKERS] domain feature - details