Hi team!
I read all your comments and this leads me to learn more.
For me and my case would be useful, even there are other ways to solve this, but I may be wrong and just have to learn more about maintenance, backup and recovery tasks.
What if when --separatetables clause is used, table definition and data are exported. Indexes, foreign keys and relations declarations are exported too, but commented, with an advice. Just an idea.
Thank you all and best regards!
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 13/05/2024 16:01, Juan Hernández wrote:
>> Do you consider useful to add a parameter (for example,
>> --separatetables) so when used the exporting file process can create a
>> different tablename.sql file for each table in database automatically?
> It'd be tricky to restore from, as you need to restore the tables in the
> right order. I think you'd still need a "main" sql file that includes
> all the other files in the right order. And using the table names as
> filenames gets tricky if the table names contain any funny characters.
It's a lot worse than that, as it's entirely possible to have circular
FK dependencies, meaning there is no "right order" if you think of
each table file as self-contained DDL plus data. Other sorts of
circularities are possible too.
pg_dump deals with that hazard by splitting things up: first create
all the tables, then load all the data, then create all the indexes
and foreign keys. You can tell it to just emit the parts relevant to
a particular table, but it's on your head whether that's actually
going to be useful in your context. I doubt that it's widely enough
useful to justify creating a special mode beyond what we already
have.
regards, tom lane