On 2/20/23 19:22, pf@xxxxxxxxxxx wrote:
On Mon, 20 Feb 2023 15:24:23 -0800 Adrian Klaver wrote:
It just dawned on me you might be doing all of this through the
pgAdmin4 GUI.
Sorry for any confusion... I get it now...
A team member uses pgAdmin4 to load separate table(s) into his DB; then
creates dump files (one per table) of those _individual_ tables which are
uploaded to me.
Given that you are using pg_restore then the dump file they are creating
is done with a custom format e.g. -Fc.
This means when you do:
pg_restore --host "localhost" --port "5432" --username "postgres"
--no-password --dbname "myname" --create --clean --verbose "dumpfile"
the --create in combination with --clean is going to DROP DATABASE and
recreate it.
I maintain a complete set of tables in my DB. pgAdmin4 is never used
here; the restore is done with a simple bash script which inserts the
dbname and dumpfile name into the command. Those restore tables should
only be created with DROP DATABASE _off_.
As I said before the solution is going to come from your end. Do not
include the --create in you pg_restore script.
All that should happen with my DB is to add these tables (99.9% of the
time, they are totally new to me).
A DROP DATABASE from the one-table per dumpfile creator is UNwanted.
Again that is your doing and you are the one that can stop it.
Looks like I really did dodge a bullet...
Again the default is to not include those options.
Glad to know pgAdmin4 has those switches.
Thanks again!!
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
