Aleksandr Furmanov wrote > Thanks, > However I am not just replicating data from 'a' to 'b', I provided > simplified example, in reality table 'b' keeps data which are going to be > merged into 'a', some rows will be updated, some added. There is some > other work has to be done on 'b' before merging into 'a' and that work > relies on 'id' from a. Three options: 1) CREATE TABLE a (id serial, name text, source_id_from_table_b integer); and during INSERT provide which record on B caused the record on A to be created. 2) Determine what can be used as a true primary key on both A and B; forgo the use of SERIAL 3) Do whatever it is you need to do one record at a time within a pl/pgsql function and capture the ID from B and the post-insert ID from A into local variables to generate a temporary mapping for doing your other work. I'd suggest #1; simply move the mapping column from "B" to "A" and perform the linking during the insert but your simplified example provide no context to evaluate if this will actually meet your needs. The main concern is that this basically models a 1-to-1(optional) relationship between A and B; such that every record in A must exist in B (assuming you disallow NULL) but B can have records that do not exist in A. Whether multiple records in A can share the same "source" record in B is undefined by can be made explicit by the choice of INDEX that you create (UNIQUE or NORMAL). David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/INSERT-RETURNING-with-values-other-than-inserted-ones-tp5758695p5758793.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
