SQL-question: returning the id of an insert querry

[Andreas Fromm]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Im building an user database with many tables keeping the data for the
Address, Phone numbers, etc which are referenced by a table where I keep
the single users. My question is, how do I get the "Id"-value of a newly
inserted address to store it in the referencing user table:

(a) INSERT INTO address VALUES (....);

(b) INSERT INTO users VALUES ( name, ... , address , ... );

where address should hold the value of the Id from the Adress table.
Do have to do an
SELECT id FROM address WHERE oid = oid_returned_by _insert(a)
or something like that after doing the insert(a) to get the correct id
value, or is there a better way to do this.

Im writing my app in Perl with DBD/DBI
Thanks in advance,

Andreas Fromm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/rhcdPkvkZVZzNY0 RApmDAJ4k4MY/zKvH2862MuHSIjD tsmIs3QCfRzaR
0zDc1bIQAOMpLur vRZ2V8JY=
=kgaA
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Scott Chapman]

On Wednesday 12 November 2003 12:31, Doug McNaught wrote:

Scott Chapman <sc********@mis chko.com> writes:

On Wednesday 12 November 2003 11:29, Doug McNaught wrote:

Scott Chapman <sc********@mis chko.com> writes:
> It would be nice if PostgreSQL could return the primary key it
> inserted with but that may not be a fool-proof solution either.
> Is there a nice way to handle this situation?

Write a database function that inserts the record and returns the
primary key value? That's probably the best way to insulate your
app from the database structure...

The function still has to know which sequence to pull from doesn't
it?

Yes. It's theoretically possible to derive that information if you
have enough system-tables-fu, but since the function knows which
table it's inserting into, it's not hard to put the proper sequence
name in as well.

I don't know much about triggers/functions in PG. Is it possible
to have a function that intercepts the information AFTER the
sequence value is added as the new primary key and then return it?
This would enable the use of a more generic function.

Sure, in the function you would basically do (I forget the exact
pl/pgsql syntax):

INSERT INTO foo VALUES (...);
SELECT currval('the_pk _sequence') INTO pk;
RETURN pk;

Doesn't remove the need to know or derive the proper sequence name.
There is no "what primary key did I just insert" built into PG. And
you will need a separate function for each table.

But this way the DB knowledge resides in the DB and you just have a
nice clean API for inserting data from the clients. The schema can
change and the API will (homefully) remain the same...

What's the process to suggest changes to PG along these lines? Say, a
proposal to make it configurable for a user to have a INSERT return the
primary key that it just inserted rather than what it returns now?

Scott

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Doug McNaught]

Scott Chapman <sc********@mis chko.com> writes:

What's the process to suggest changes to PG along these lines? Say, a
proposal to make it configurable for a user to have a INSERT return the
primary key that it just inserted rather than what it returns now?

What if you have a multicolumn PK?

I'm not actually sure PG keeps track of "primary keyness" -- I think
it translates a PRIMARY KEY constraint into NOT NULL UNIQUE when the
table is created. So it might be really hard to implement your
feature, even if you can figure out what should happen for multicolumn
PKs.

-Doug

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Andrew Sullivan]

On Wed, Nov 12, 2003 at 12:35:27PM -0800, Scott Chapman wrote:

What's the process to suggest changes to PG along these lines? Say, a
proposal to make it configurable for a user to have a INSERT return the
primary key that it just inserted rather than what it returns now?

Take a well-worked-out proposal to the folks on -hackers, and either
wait for someone else to do the work (unlikely), or do the work
yourself, and submit a patch.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<an****@liberty rms.info> M2P 2A8
[phone] x110
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[scott.marlowe]

On Wed, 12 Nov 2003, Scott Chapman wrote:

On Wednesday 12 November 2003 12:31, Doug McNaught wrote:

Scott Chapman <sc********@mis chko.com> writes:

On Wednesday 12 November 2003 11:29, Doug McNaught wrote:
> Scott Chapman <sc********@mis chko.com> writes:
> > It would be nice if PostgreSQL could return the primary key it
> > inserted with but that may not be a fool-proof solution either.
> > Is there a nice way to handle this situation?
>
> Write a database function that inserts the record and returns the
> primary key value? That's probably the best way to insulate your
> app from the database structure...

The function still has to know which sequence to pull from doesn't
it?

Yes. It's theoretically possible to derive that information if you
have enough system-tables-fu, but since the function knows which
table it's inserting into, it's not hard to put the proper sequence
name in as well.

I don't know much about triggers/functions in PG. Is it possible
to have a function that intercepts the information AFTER the
sequence value is added as the new primary key and then return it?
This would enable the use of a more generic function.

Sure, in the function you would basically do (I forget the exact
pl/pgsql syntax):

INSERT INTO foo VALUES (...);
SELECT currval('the_pk _sequence') INTO pk;
RETURN pk;

Doesn't remove the need to know or derive the proper sequence name.
There is no "what primary key did I just insert" built into PG. And
you will need a separate function for each table.

But this way the DB knowledge resides in the DB and you just have a
nice clean API for inserting data from the clients. The schema can
change and the API will (homefully) remain the same...

What's the process to suggest changes to PG along these lines? Say, a
proposal to make it configurable for a user to have a INSERT return the
primary key that it just inserted rather than what it returns now?

I wouldn't suggest changing current bevaiour (i.e. the number of rows
inserted is probably a SQL SPEC thing) but to have each serial column in a
table be addressable so you'd just do:

select tablename.field name.currval;

and you'd get the currval back for the serial. note that if the serial
value was implemented by hand like:

create table test (id int primary key default
'myseq'::text|| nextval('seqnam e')::text);

that currval or the equivalent would actually give back the key inserted,
'myseqx' where x was the sequence number.

The folks are -hackers are always willing to listen to a good idea, but
they've got plenty on their plates, so this kind of thing needs to be at
the least thought out well enough so they won't have lots of
implementation problems with the plan.

It might also be possible to have the serial type create a plsql function
that has the name tablename_field name_currval() and returns the last
currval('seqnam e') with a simple wrapper. That solution would be fairly
easy to implement, and would be quite useful.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

Doug McNaught <do**@mcnaught. org> writes:

Scott Chapman <sc********@mis chko.com> writes:

What's the process to suggest changes to PG along these lines? Say, a
proposal to make it configurable for a user to have a INSERT return the
primary key that it just inserted rather than what it returns now?

What if you have a multicolumn PK?

Or a PK that's not an integer? Or no PK at all?

There's not likely to be any interest in hotwiring INSERT to return
a different command tag than it does now; that would break too much
existing code. There has been some talk of inventing an "INSERT
.... RETURNING ..." syntax extension that would return whatever
expressions you cared to compute from inserted rows --- but in the form
of a SELECT result, not by trying to squeeze it into a command tag.
I think the last discussion of this was a year or so back in pg-hackers.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Greg Stark]

"scott.marl owe" <sc***********@ ihs.com> writes:

select tablename.field name.currval;

That syntax would be problematic, it would mean to select all rows from
tablename and evaluate fieldname.currv al for each one. Actually it's worse, it
would be confused with schemas I think.

The postgres-ish way to do this would be to create a function like currval
that took a table and column and told you the currval of the sequence
associated with it.

Well you can already do something like that:

db=> create or replace function currval(text,te xt) returns bigint as 'select currval($1 || ''_'' || $2 || ''_seq'')' language sql strict;
CREATE FUNCTION

db=> create table test (a serial);
NOTICE: CREATE TABLE will create implicit sequence "test_a_seq " for "serial" column "test.a"
CREATE TABLE

db=> insert into test(a) values (default);
INSERT 14080230 1

db=> select currval('test', 'a');
currval
---------
1
(1 row)

The only problem arises if you use table names or column names that cause
postgres to truncate the resulting sequence name. This could be worked-around
by using the dependency information instead of depending on the naming scheme.

But as long as you do that the above works fine. And means you could always
change your naming scheme or method for looking up the associated sequence
later without changing all your sql.

--
greg
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly