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

Re: [SQL] INSERT w/o variable names for a SERIAL type?

From: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: [SQL] INSERT w/o variable names for a SERIAL type?
Date: 2000-02-27 19:44:02
Message-ID: 20000227134402.A5030@rice.edu (view raw or flat)
Thread:
Lists: pgsql-sql
On Sun, Feb 27, 2000 at 02:04:42PM -0500, Bruce Momjian wrote:
> > > INSERT INTO my_table VALUES (a, b, c, DEFAULT, x, y, z, ...);
> > 
> > I think that is legal SQL92 syntax, but Postgres doesn't accept it
> > at present.
> > 
> 
> The problem is when you are inserting >50 columns, it is a pain.  The
> use of DEFAULT would also allow SERIAL columns to get the proper
> nextval(), rather than having specify the nextval() call specifically.

This, I think, is the best reason for doing it: even if you call
out the column names, as Tom rightly mentions is best, using DEFAULT
allows writing INSERTs without depending on the details of how SERIAL
is implemented in pgsql: i.e. knowing the algorithm for constructing
the sequenec name.

> 
> Added to TODO.


Perhaps we should note which items on the TODO list are needed for what
level of SQL92 compliance. This one, for example, is not necessary for
ENTRY level, but required at INTERMEDIATE. Not that that should stop
anyone from implementing it:  SQL92 Entry is a surprisingly limited
subset, and we have a lot of INTERMEDIATE and FULL features, already.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005


In response to

Responses

pgsql-sql by date

Next:From: maillistDate: 2000-02-27 22:45:31
Subject: Rule (which multiple actions) problem with history table.....
Previous:From: Bruce MomjianDate: 2000-02-27 19:04:42
Subject: Re: [SQL] INSERT w/o variable names for a SERIAL type?

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