From: | Szymon Guz <mabewlun(at)gmail(dot)com> |
---|---|
To: | Jonathan Tripathy <jonnyt(at)abpni(dot)co(dot)uk> |
Cc: | Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Return key from query |
Date: | 2010-11-03 17:33:12 |
Message-ID: | AANLkTik_fqp3_TsZ-U6+P3UQCgrOPiE8-g1iUNTKCXHU@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 3 November 2010 17:46, Jonathan Tripathy <jonnyt(at)abpni(dot)co(dot)uk> wrote:
>
>
>>> 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 :(
>
>
>
>
>
Hi,
why harder? Simple INSERT RETURNING doesn't work for you?
regards
Szymon
From | Date | Subject | |
---|---|---|---|
Next Message | Gabriel Dinis | 2010-11-03 17:54:57 | Re: PHP Web Auditing and Authorization |
Previous Message | Andreas Kretschmer | 2010-11-03 16:55:39 | Re: How to configure pgsql in such a way that it is always recoverable? |