Thread: going crazy with serial type

OK.  My background is in mysql, and I've been converting over to psql.  Just
by way of background.

I do !NOT! understand how the SERIAL type works.  I want something
like I had in mysql that would generate new, unique numbers, each time
I added a new record.  I want something that sits down, shuts up, and
just GIVES me the number on demand.  (I also want a guarantee that the
unique number is consecutive, and is never zero or negative.)  In short,
I want the AUTO_INCREMENT behavior.

But so far it's been one giant headache.  Tell me, how do I insert
new records into a table *without* specifying an actual number?  In
mysql it's just an empty field.  I have been unable to determine how
to do this in psql other than to ascertain it certainly isn't through
the same way.

I've been through the documentation, but for some reason, no one seems
to think a programmer would ever want functionality like mysql's
AUTO_INCREMENT, so as far as I can tell, it's not even addressed.

I'd appreciate any help.  I basically have a table:

create table mytable (mytable_id serial, a int, b int);

and

insert into mytable ('', 1, 2); is accepted but then following
insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"


Thanks,
--Cindy
--
ctmoore@uci.edu

Cindy <ctmoore@uci.edu> writes:

> OK.  My background is in mysql, and I've been converting over to psql.  Just
> by way of background.

We like to see that.  ;)

>                                      (I also want a guarantee that the
> unique number is consecutive, and is never zero or negative.)

Consecutive you're not going to get (rollbacks will cause gaps in the
sequence).  There are good reasone laid out in the docs as to why this
happens.  If you have to have consecutive values in all cases, there
are ways to do it that involve a little more work--see the mailing
list archives; it's been discussed several times.

> create table mytable (mytable_id serial, a int, b int);
>
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"

INSERT INTO mytable (a, b) VALUES (1,2);
INSERT INTO mytable (a, b) VALUES (5,6);

SELECT * FROM mytable;

In other words, a non-specified value for a column will cause the
DEFAULT value to be inserted.  Since SERIAL uses the DEFAULT
mechanism, it "just works".

Good luck!

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

> I've been through the documentation, but for some reason, no one seems
> to think a programmer would ever want functionality like mysql's
> AUTO_INCREMENT, so as far as I can tell, it's not even addressed.

Actually, it has it's own section in the manual:

http://www.us.postgresql.org/users-lounge/docs/7.1/user/datatype.html#DATATY
PE-SERIAL

As well as a two questions in the FAQ:

http://www.us.postgresql.org/docs/faq-english.html#4.15.1
http://www.us.postgresql.org/docs/faq-english.html#4.15.2

And even more information in the online book:

http://www.ca.postgresql.org/docs/aw_pgsql_book/node75.html
http://www.ca.postgresql.org/docs/aw_pgsql_book/node76.html

> I'd appreciate any help.  I basically have a table:
>
> create table mytable (mytable_id serial, a int, b int);
>
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"

Just a guess here, but it seems that '' is being cast into an integer as a
0, therefore your inserts end up as:

insert into mytable (0, 1, 2);
insert into mytable (0, 5, 6);

What you want to do is either leave out the serial field:

insert into mytable (a, b) values (1, 2);
insert into mytable (a, b) values (5, 6);

Or explicitly give the serial a NULL value:

insert into mytable (NULL, 1, 2);
insert into mytable (NULL, 5, 6);

Hope this helps,

Greg

I don't believe you have to enter the serial at all.

So instead of this.

insert into mytable ('', 1, 2);

Try this.

insert into mytable (a, b) VALUES (1, 2);

I think that will work the way you want. Although I am a beginner myself.

Good luck.


Cindy wrote:

>OK.  My background is in mysql, and I've been converting over to psql.  Just
>by way of background.
>
>I do !NOT! understand how the SERIAL type works.  I want something
>like I had in mysql that would generate new, unique numbers, each time
>I added a new record.  I want something that sits down, shuts up, and
>just GIVES me the number on demand.  (I also want a guarantee that the
>unique number is consecutive, and is never zero or negative.)  In short,
>I want the AUTO_INCREMENT behavior.
>
>But so far it's been one giant headache.  Tell me, how do I insert
>new records into a table *without* specifying an actual number?  In
>mysql it's just an empty field.  I have been unable to determine how
>to do this in psql other than to ascertain it certainly isn't through
>the same way.
>
>I've been through the documentation, but for some reason, no one seems
>to think a programmer would ever want functionality like mysql's
>AUTO_INCREMENT, so as far as I can tell, it's not even addressed.
>
>I'd appreciate any help.  I basically have a table:
>
>create table mytable (mytable_id serial, a int, b int);
>
>and
>
>insert into mytable ('', 1, 2); is accepted but then following
>insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"
>
>
>Thanks,
>--Cindy
>

--
Brian Avis
SEARHC Medical Clinic
Juneau, AK 99801
(907) 463-4049
cd /pub
more beer

On Thu, 31 Jan 2002, Cindy wrote:

> I do !NOT! understand how the SERIAL type works.  I want something
> like I had in mysql that would generate new, unique numbers, each time
> I added a new record.  I want something that sits down, shuts up, and
> just GIVES me the number on demand.  (I also want a guarantee that the
> unique number is consecutive, and is never zero or negative.)  In short,
> I want the AUTO_INCREMENT behavior.

You won't get that.  serial (and sequences) are guaranteed to give numbers
that haven't shown up in the sequence (note: you can still get duplicates
if you set values yourself, you can get around this with triggers - there
was a recent example on one of the mailing lists I believe) not
consecutive numbers due to concurrency concerns (if one transaction asks
for a number and then a second also asks for a number, you need to wait
for transaction one to commit or rollback before you can give the second a
number if you want to guarantee consecutive numbers).

> But so far it's been one giant headache.  Tell me, how do I insert
> new records into a table *without* specifying an actual number?  In
> mysql it's just an empty field.  I have been unable to determine how
> to do this in psql other than to ascertain it certainly isn't through
> the same way.
You don't insert a value into the field (see below).  There's a difference
between inserting an empty value or even a NULL and not inserting a value.

> I'd appreciate any help.  I basically have a table:
> create table mytable (mytable_id serial, a int, b int);
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"
insert into mytable (a,b) values (1,2);
insert into mytable (a,b) values (5,6);

"Gregory Wood" writes:
 >> I've been through the documentation, but for some reason, no one seems
 >> to think a programmer would ever want functionality like mysql's
 >> AUTO_INCREMENT, so as far as I can tell, it's not even addressed.
 >
 >Actually, it has it's own section in the manual:

Of course, making a statement like I did is about the fastest way to
find out what you missed :).  However:

 >http://www.us.postgresql.org/users-lounge/docs/7.1/user/datatype.html#DATATY
 >PE-SERIAL

Yes, but this does not give an example of how to use it.  Ie, what
I need to do to insert properly.  I found this, but it was not helpful,
other than to know I could (in theory) use SERIAL rather than AUTO_INCREMENT.

 >As well as a two questions in the FAQ:
 >
 >http://www.us.postgresql.org/docs/faq-english.html#4.15.1
 >http://www.us.postgresql.org/docs/faq-english.html#4.15.2

OK.  These are helpful, but didn't answer my question of how to make
the insert call unless you're trying to tell me I should call next val
in order to get the value to assign into the record myself.  That
seems to me a very backwards, two step, way to do it, and it doesn't
suprise me I didn't manage to find this.

 >And even more information in the online book:
 >
 >http://www.ca.postgresql.org/docs/aw_pgsql_book/node75.html
 >http://www.ca.postgresql.org/docs/aw_pgsql_book/node76.html

Aha.  Yes, that would have helped.  I never did stumble on the
www.ca.postgresql.org site, though.  Thanks for the reference.

 >Just a guess here, but it seems that '' is being cast into an integer
 >as a 0,

Looks like it.

 >What you want to do is either leave out the serial field:
...
 >Or explicitly give the serial a NULL value:

I'll try the null value!  I have rather more than two fields in
my actual table, of course, which would make listing them tedious.

Thanks!
--
Cindy
ctmoore@uci.edu

Le Jeudi 31 Janvier 2002 18:40, Cindy a écrit :

> create table mytable (mytable_id serial, a int, b int);
>
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"
>

insert into mytable (a,b) values (1,2);
insert into mytable (a,b) values (5,6);

>
> Thanks,
> --Cindy

"Gregory Wood" <gregw@com-stock.com> writes:
> [ lots of good advice snipped ]

> Or explicitly give the serial a NULL value:

> insert into mytable (NULL, 1, 2);
> insert into mytable (NULL, 5, 6);

Oops, struck out on your last at-bat :-(.  The above will insert NULLs.

The *only* way to get the default value inserted is not to specify
the column at all in the insert.  The way you suggested works:

> insert into mytable (a, b) VALUES (1, 2);

Another option is to arrange the columns of the table so that the
one(s) you typically default are at the end, and then you can leave
off the column name list in INSERT:

create table mytable (a int, b int, id serial);

insert into mytable values (1, 2);

However, a lot of people consider it good practice to explicitly write
out a column name list in every INSERT anyway.  The above shortcut will
come back to bite you if you ever rearrange the columns again.  An
INSERT with column names listed is relatively impervious to schema
rearrangements.

            regards, tom lane

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> You won't get that.  serial (and sequences) are guaranteed to give numbers
> that haven't shown up in the sequence (note: you can still get duplicates
> if you set values yourself, you can get around this with triggers -

The SERIAL type implicitly adds a UNIQUE index, so you don't need to
worry about uniqueness even if you sometimes manually insert values.

Stephan's correct that sequences do not guarantee consecutive numbers,
only distinct numbers (because numbers obtained by transactions that
later fail won't get recycled).  We consider that we have good and
sufficient reasons for doing it that way.

Cindy also mentioned a requirement that the numbers never be <= 0.
While the sequence won't generate such values (at least not with default
parameters), there wouldn't be anything stopping a manual insertion of
a value <= 0.  If it's really important to prevent that, she could add
something like CHECK (id > 0) to the column definition.

            regards, tom lane

OK, next question.  I'm trying to use nextval/currval and I'm getting
this:

search_info=# select currval('state_vectors_id_seq');
ERROR:  state_vectors_id_seq.currval is not yet defined in this session
search_info=# select id from state_vectors;
 id
----
  1
(1 row)


shouldn't the first select have returned 1?  The state_vectors_id_seq
is the sequence created by declaring id SERIAL in the table
state_vectors, and I've done one INSERT INTO state_vectors VALUES
(nextval('state_vectors_id_seq'), ... ); which worked fine and is
where the 1 comes from.  (I'm interested in finding out the value used
for the most recent insert, and currval seemed like a pretty painless
way of doing so.)

(I'm basing this on 4.15.2 of the postgresql faq kindly supplied
earlier.)

--CIndy

CREATE SEQUENCE test_seq

CREATE TABLE test
(
    test_id INTEGER DEFAULT NEXTVAL('test_seq'),
    test_name VARCHAR(64),
    CONSTRAINT test_pk PRIMARY KEY(test_id)
);

INSERT INTO test (test_name) VALUES ('Test Name');
INSERT INTO test (test_name) VALUES ('Test Name2');

This is what you are looking for i believe

The sequence number

Note i believe SERIAL just creates a sequence with the table name _seq and
then defaults that field to that value

Darren Ferguson

On Thu, 31 Jan 2002, Cindy wrote:

>
> OK.  My background is in mysql, and I've been converting over to psql.  Just
> by way of background.
>
> I do !NOT! understand how the SERIAL type works.  I want something
> like I had in mysql that would generate new, unique numbers, each time
> I added a new record.  I want something that sits down, shuts up, and
> just GIVES me the number on demand.  (I also want a guarantee that the
> unique number is consecutive, and is never zero or negative.)  In short,
> I want the AUTO_INCREMENT behavior.
>
> But so far it's been one giant headache.  Tell me, how do I insert
> new records into a table *without* specifying an actual number?  In
> mysql it's just an empty field.  I have been unable to determine how
> to do this in psql other than to ascertain it certainly isn't through
> the same way.
>
> I've been through the documentation, but for some reason, no one seems
> to think a programmer would ever want functionality like mysql's
> AUTO_INCREMENT, so as far as I can tell, it's not even addressed.
>
> I'd appreciate any help.  I basically have a table:
>
> create table mytable (mytable_id serial, a int, b int);
>
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"
>
>
> Thanks,
> --Cindy
> --
> ctmoore@uci.edu
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

Cindy,

You are quite close to the solution.  You already have the correct
datatype, now all you need is the correct syntax.

Here's an example:

CREATE TABLE foo (
    bar        SERIAL PRIMARY KEY,
    a        int,
    b        int,
);

Now insert into this table like this:

INSERT INTO foo (a, b) VALUES (1, 2);
INSERT INTO foo (a, b) VALUES (3, 4);

To verify that it works do this:

processdata=> SELECT * FROM foo;
 bar | a | b
-----+---+---
   1 | 1 | 2
   2 | 3 | 4
(2 rows)

Notice that I didn't specify a value for the bar column when I inserted
my values, this causes PostgreSQL to choose the default value (which in
this case is the nextval() from the sequence created by the serial
type).

Now, integers provided in this fashion are guaranteed to be unique each
time, but they aren't guaranteed to be consecutive.  PostgreSQL doesn't
try and reuse sequence numbers on failure so if you have a lot of failed
inserts you *will* see holes in your sequences.  This means that the
numbers might be (1, 2, 4, 5, 7) or something instead of (1, 2, 3, 4,
5).  Personally, I think that it is an acceptable price to pay for a
database where inserts don't lock up the entire table, but if your
numbers have to be consecutive it is something to think about.

Hope this was helpful,
Jason

On Thu, 2002-01-31 at 12:40, Cindy wrote:
>
> OK.  My background is in mysql, and I've been converting over to psql.  Just
> by way of background.
>
> I do !NOT! understand how the SERIAL type works.  I want something
> like I had in mysql that would generate new, unique numbers, each time
> I added a new record.  I want something that sits down, shuts up, and
> just GIVES me the number on demand.  (I also want a guarantee that the
> unique number is consecutive, and is never zero or negative.)  In short,
> I want the AUTO_INCREMENT behavior.
>
> But so far it's been one giant headache.  Tell me, how do I insert
> new records into a table *without* specifying an actual number?  In
> mysql it's just an empty field.  I have been unable to determine how
> to do this in psql other than to ascertain it certainly isn't through
> the same way.
>
> I've been through the documentation, but for some reason, no one seems
> to think a programmer would ever want functionality like mysql's
> AUTO_INCREMENT, so as far as I can tell, it's not even addressed.
>
> I'd appreciate any help.  I basically have a table:
>
> create table mytable (mytable_id serial, a int, b int);
>
> and
>
> insert into mytable ('', 1, 2); is accepted but then following
> insert into mytable ('', 5, 6); etc, is rejected due to "duplicate key"
>
>
> Thanks,
> --Cindy
> --
> ctmoore@uci.edu
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

For some reason unknown to myself if you have not initiated a nextval in
the same psql command line before calling currval then that is the error
msg you will get.

If you do nextval then a currval after it then that error will disappear

Darren Ferguson

On Thu, 31 Jan 2002, Cindy wrote:

>
>
> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
>
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session
> search_info=# select id from state_vectors;
>  id
> ----
>   1
> (1 row)
>
>
> shouldn't the first select have returned 1?  The state_vectors_id_seq
> is the sequence created by declaring id SERIAL in the table
> state_vectors, and I've done one INSERT INTO state_vectors VALUES
> (nextval('state_vectors_id_seq'), ... ); which worked fine and is
> where the 1 comes from.  (I'm interested in finding out the value used
> for the most recent insert, and currval seemed like a pretty painless
> way of doing so.)
>
> (I'm basing this on 4.15.2 of the postgresql faq kindly supplied
> earlier.)
>
> --CIndy
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

On Thu, 31 Jan 2002, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > You won't get that.  serial (and sequences) are guaranteed to give numbers
> > that haven't shown up in the sequence (note: you can still get duplicates
> > if you set values yourself, you can get around this with triggers -
>
> The SERIAL type implicitly adds a UNIQUE index, so you don't need to
> worry about uniqueness even if you sometimes manually insert values.

Right, but you get the intermittent errors in that case since the serial
doesn't skip the values that would error (which you might expect if you're
guaranteeing distinct numbers in a column).  When looked at as what it is
(an integer with a default) it makes sense, but if you don't know that
it's a bit unexpected.

> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
>
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session
> search_info=# select id from state_vectors;
>  id
> ----
>   1
> (1 row)
>
>
> shouldn't the first select have returned 1?

Yes and/or no. The way currval is handled is a bit... weird at first glance.
It's that way for a reason though:

Lets say you have two users, Ann and Bob. Ann inserts a row, which receives
a value of 1. Bob inserts a row with a value of 2. Ann then inserts a row
into another table, which references that first table. Because of the
reference, she wants to use the id value that was just inserted by her,
which is 1. If currval just grabbed the last sequence value, she would be
inserting a value of 2, which actually refers to Bob's insert. Bad.

So the way currval works is it grabs the last value of nextval, as executed
by the USER (or more specifically, that user's connection, i.e. session).
This means that when Ann does her insert, the nextval increments to 1 (the
initial value) and her currval is 1. When Bob does his insert, his nextval
increments to 2 and he gets a currval of 2, while Ann still retains her
currval of 1 (since it was Bob's session that incremented nextval to 2 and
not hers). That way Ann can use the sequence value that she just inserted
elsewhere, without fear of mistakenly using Bob's id value.

Now, to go back to the "state_vectors_id_seq.currval is not yet definted in
this session" error you received. Since the currval is populated by the last
value of nextval in that session, it can only be used after nextval has been
called (either explicitly, or through a default serial value). In other
words, you can only read currval after you perform an INSERT, or explicitly
call nextval.

Greg

Cindy <ctmoore@uci.edu> writes:

> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
>
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session

You need to do an explicit or implicit 'nextval' in a transaction
before 'currval' will work in that transaction.  So you can do:

BEGIN WORK;
INSERT INTO mytable (a, b) VALUES (1,2);
SELECT nextval('mytable_id_seq');
<do something with it>
COMMIT WORK;

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

Cindy wrote:

>OK, next question.  I'm trying to use nextval/currval and I'm getting
>this:
>
>search_info=# select currval('state_vectors_id_seq');
>ERROR:  state_vectors_id_seq.currval is not yet defined in this session
>search_info=# select id from state_vectors;
> id
>----
>  1
>(1 row)
>
>
>shouldn't the first select have returned 1?  The state_vectors_id_seq
>
Nope.  currval() is per session, so if you haven't called nextval()
during the current connection, you'll see exactly what you saw.

test=# create sequence testseq;
CREATE
test=# select currval('testseq');
ERROR:  testseq.currval is not yet defined in this session
test=# select nextval('testseq');
 nextval
---------
       1
(1 row)

test=# select currval('testseq');
 currval
---------
       1
(1 row)

test=# \q

$ psql test

Welcome to psql, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

test=# select currval('testseq');
ERROR:  testseq.currval is not yet defined in this session
test=#

-Fran

Cindy <ctmoore@uci.edu> writes:
> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session

currval is defined to return the value most recently returned by nextval
in the current session.  Thus, without a prior nextval, you get an error.
The reason for this is to make it useful in a situation where multiple
clients are concurrently obtaining values from the same sequence.

The 7.2 documentation set has been improved (or at least I'd like to
think so) over 7.1's description of sequence stuff.  You may find that
reading

http://developer.postgresql.org/docs/postgres/datatype.html#DATATYPE-SERIAL
http://developer.postgresql.org/docs/postgres/functions-sequence.html
http://developer.postgresql.org/docs/postgres/sql-createsequence.html

reduces your level of confusion.  (Or not, but at least we tried...)
Note that 7.1 does not have the int8-based sequences described there,
but other than that I believe all the info carries back to 7.1.

            regards, tom lane

On Thu, 31 Jan 2002, Cindy wrote:

> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
>
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session
> search_info=# select id from state_vectors;
>  id
> ----
>   1
> (1 row)
>
>
> shouldn't the first select have returned 1?  The state_vectors_id_seq
> is the sequence created by declaring id SERIAL in the table
> state_vectors, and I've done one INSERT INTO state_vectors VALUES
> (nextval('state_vectors_id_seq'), ... ); which worked fine and is
> where the 1 comes from.  (I'm interested in finding out the value used
> for the most recent insert, and currval seemed like a pretty painless
> way of doing so.)
>
> (I'm basing this on 4.15.2 of the postgresql faq kindly supplied
> earlier.)

Well, as you've run into, it doesn't quite work like that.  currval gives
you the most recently assigned number to your session, not the database as
a whole.  What are you trying to do with the id once you get it?

"Gregory Wood" <gregw@com-stock.com> writes:
> [ excellent explanation ]

Somebody ought to pull out the better parts of this thread and put
together an article for the techdocs.postgresql.org site...

            regards, tom lane


> Yes and/or no. The way currval is handled is a bit... weird at first glance.
> It's that way for a reason though:

> Lets say you have two users, Ann and Bob. Ann inserts a row, which receives
> a value of 1. Bob inserts a row with a value of 2. Ann then inserts a row
> into another table, which references that first table. Because of the
> reference, she wants to use the id value that was just inserted by her,
> which is 1. If currval just grabbed the last sequence value, she would be
> inserting a value of 2, which actually refers to Bob's insert. Bad.

> So the way currval works is it grabs the last value of nextval, as executed
> by the USER (or more specifically, that user's connection, i.e. session).
> This means that when Ann does her insert, the nextval increments to 1 (the
> initial value) and her currval is 1. When Bob does his insert, his nextval
> increments to 2 and he gets a currval of 2, while Ann still retains her
> currval of 1 (since it was Bob's session that incremented nextval to 2 and
> not hers). That way Ann can use the sequence value that she just inserted
> elsewhere, without fear of mistakenly using Bob's id value.

> Now, to go back to the "state_vectors_id_seq.currval is not yet definted in
> this session" error you received. Since the currval is populated by the last
> value of nextval in that session, it can only be used after nextval has been
> called (either explicitly, or through a default serial value). In other
> words, you can only read currval after you perform an INSERT, or explicitly
> call nextval.

> Greg

Darren Ferguson wrote:
> For some reason unknown to myself if you have not initiated a nextval in
> the same psql command line before calling currval then that is the error
> msg you will get.

    Slightly  wrong. This is the correct behaviour if you haven't
    called NEXTVAL in that session before.

    The reason is that the SQL standard  defines  CURRVAL  to  be
    last value returned by NEXTVAL "in this session".


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Jan Wieck <janwieck@yahoo.com> writes:
>     The reason is that the SQL standard  defines  CURRVAL  to  be
>     last value returned by NEXTVAL "in this session".

Sequences are in the SQL standard?  I'm not finding 'em there...

            regards, tom lane

Hi Cindy,

I'd also recommend you take a look at :

http://techdocs.postgresql.org/college/001_sequences/

As this is a CBT which explains things pretty well.

:-)

Regards and best wishes,

Justin Clift


Cindy wrote:
>
> OK, next question.  I'm trying to use nextval/currval and I'm getting
> this:
>
> search_info=# select currval('state_vectors_id_seq');
> ERROR:  state_vectors_id_seq.currval is not yet defined in this session
> search_info=# select id from state_vectors;
>  id
> ----
>   1
> (1 row)
>
> shouldn't the first select have returned 1?  The state_vectors_id_seq
> is the sequence created by declaring id SERIAL in the table
> state_vectors, and I've done one INSERT INTO state_vectors VALUES
> (nextval('state_vectors_id_seq'), ... ); which worked fine and is
> where the 1 comes from.  (I'm interested in finding out the value used
> for the most recent insert, and currval seemed like a pretty painless
> way of doing so.)
>
> (I'm basing this on 4.15.2 of the postgresql faq kindly supplied
> earlier.)
>
> --CIndy
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi