From: | "Igor Neyman" <ineyman(at)perceptron(dot)com> |
---|---|
To: | "Jonathan Tripathy" <jonnyt(at)abpni(dot)co(dot)uk>, "Rob Sargent" <robjsargent(at)gmail(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Return key from query |
Date: | 2010-11-03 20:15:45 |
Message-ID: | F4C27E77F7A33E4CA98C19A9DC6722A206B21E83@EXCHANGE.corp.perceptron.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: Jonathan Tripathy [mailto:jonnyt(at)abpni(dot)co(dot)uk]
> Sent: Wednesday, November 03, 2010 12:46 PM
> To: Rob Sargent; pgsql-general(at)postgresql(dot)org
> Subject: Re: Return key from query
>
>
> >>
> >> Sorry, I don't get it. I usually have an application that
> knows if it
> >> wants to write some data to database, or not. So it writes
> the data,
> >> and just gets from database the id that was set by
> database. No need
> >> of getting the id earlier in a transaction, although the simple
> >> insert that saves the data runs in a transaction of course.
> >> Another approach could be just getting the id from database, and
> >> saving the data using that id. If someone puts there any
> complicated
> >> logic between getting id and saving data, it is just a very bad
> >> software design, that has nothing common with the id/uuid problem.
> >>
>
> All my software is doing is running a simple INSERT query on
> a table, with the primary key auto-incremented. I just have
> no way of knowing what the new ID is once the query is done.
> My problem is simpler than soft folk here think, however I
> feer that the solution is harder than I think :(
>
No, it's not hard at all.
You were already given a solution: INSERT with "RETURNING" clause.
Check PG documentation regarding this clause.
Regards,
Igor Neyman
From | Date | Subject | |
---|---|---|---|
Next Message | Filip Rembiałkowski | 2010-11-04 00:07:00 | Re: Group by and lmit |
Previous Message | Rob Richardson | 2010-11-03 20:09:57 | Re: Autovacuum not started because of misconfiguration |