On 2/20/23 19:22, pf@pfortin.com 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@aklaver.com
