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?
