From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: INSERT question |
Date: | 2001-11-15 22:03:38 |
Message-ID: | 20011115160338.D4187@rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Thu, Nov 15, 2001 at 03:03:00PM -0500, Roland Roberts wrote:
> >>>>> "Jason" == Jason Earl <jason(dot)earl(at)simplot(dot)com> writes:
>
> Jason> Even better, however, is to use the functions nextval() and
> Jason> currval() like so:
>
> Jason> INSERT INTO parent_table (data) values ('some data');
> Jason> INSERT INTO child_table (parent, more_data)
> Jason> (currval('parent_table_p_key_seq'),
> Jason> 'more data');
>
> The above is probably the best for a pure-SQL way with the caveat
> that it should be wrapped in a transaction or currval() may not be
> what you expect; i.e., another client may add a row and you get a
> value different from what you inserted.
This is one of the only FMAQ I've ever seen: (Frequently Mis-Answered
Question)
Read the docs for currval(): it returns the value _last sent to
this connection_, so is multiuser safe. The _only_ caveat is that in
the presence of connection pooling, your problem as described might
occur. However, since the two inserts above _should_ be wrapped in a
transaction, I'd say any connection pool that shares a connection with
an open transaction on it is broken, anyway.
Ross
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2001-11-15 22:09:02 | Re: INSERT question |
Previous Message | Aasmund Midttun Godal | 2001-11-15 21:50:49 | Re: [SQL] PL/pgSQL examples NOT involving functions |