Re: I have an exporting need...

From: Juan Hernández <dejesusog(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: I have an exporting need...
Date: 2024-05-20 23:46:43
Message-ID: CAEPHxKfnv9vtp+mxPt_O7hPNnYnAH436Xp1=EmhYTBD11ZOxWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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!

Juan de Jesús

El mar, 14 may 2024 a las 10:54, Tom Lane (<tgl(at)sss(dot)pgh(dot)pa(dot)us>) escribió:

> Heikki Linnakangas <hlinnaka(at)iki(dot)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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-05-21 01:31:08 Re: Injection points: preloading and runtime arguments
Previous Message David Steele 2024-05-20 21:41:59 Re: pg_combinebackup does not detect missing files