Hi, imagine I have a database containing normalized data: a whole bunch of tables all related via foreign keys (i.e. the thing one should usually have ;) ). So there is a dependency graph: all records relate to others in some tree-like fashion (has-many, belongs-to, etc.) Now I want to grab some part of the data, on a certain condition (let's say all records belonging to user 'Bob', if there is a "user" table somewhere at the tree-bottom), and move it to another database with the very same layout - which is already populated with data and runs a different instance of the same application. Grabbing the intended records is just some dead-simple Selects. But then inserting them into the other database is not fun, because some primary keys will likely collide. And if we start to update the primary keys to new unique values, we must consequently update ALL the foreign keys throughout the entire tree of tables. How to do this with two tables connected via one foreign key, that is explained a dozen times in Stackoverflow. But what if the tree is 50 tables and 120 foreign key columns? It can be done. But probably not manually. So, as this seems a very usual use-case for normalized data, is there any tooling available? Anywhere? (I searched, I didn't find.) Also, it seems the provided commands are not very supporting. Try to do an Insert and *always* create a new PK from the sequence, and return the old and the new PK for the inserted row. It seems this does not work without either naming all the other columns explicitely in the insert (impossible, they are always different) or establishing some trigger functions... Different example, same general problem: Imagine I have such a tree of normalized tables, and I want to grab a part of it and roll only that part back in time, to some state it was X weeks ago. (That's possible if we store records of changes in an extra column within the rows themselves. It might even be possible with some postgres-internal data, which has a knowledge of history - but there seems no API access to that.) But I want to have this working on click-button, independent of the table layouts, only with a basic graph of the dependency tree and with an unlimited number of involved tables, i.e.: maintainable. I have searched for solutions (or building blocks to solutions) for these and similar problems, and didn't find much. I don't understand that - SQL is old, normalization is old, (even postgres has already become quite old) and these are genuine issues. It can't be I'm the only one thinking about such things. So maybe I'm looking at the wrong place? Any ideas welcome. Cheers, PMc
