From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Ayden Gera <aydengera(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-novice(at)lists(dot)postgresql(dot)org |
Subject: | Re: PGDump question/issue |
Date: | 2025-04-26 12:04:43 |
Message-ID: | CAKAnmm+BKpMQXiL2ZdXMMf_xg97o_iY0WigFBe2nQ=yU=q++0w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
>
> SaaS provided PGDump
Is this a custom dump, or just a bunch of ASCII ? Run "file" against it to
find out.
Im open to any other ideas on how to get around the drop table that comes
> in PG Dump from DB A.
Sounds like these drop tables are a good thing. You asked about removing
all the data. DROP TABLE does that. Further, if the schema sent by the SaaS
ever changes, you would want to know that, so it's in your best interest to
keep it's schema-creation commands around (which has the drop-if-exists as
part of that).
If your dumps are custom, the solution Laurenz provided is a good one.
If it is *only* RLS that needs to be recreated, that can be done. It's
weird you don't have a list somewhere of your current settings, but here's
another workaround to create the list on the fly and apply it:
// Save the existing RLS information to a file:
pg_dump -d mydb --section=post-data | grep -E 'ROW LEVEL SECURITY|CREATE
POLICY' > mydb.rls.sql
// Eyeball mydb.rls.pg to make sure it look sane; that's not a 100%
bulletproof regex
// Import the schema from SaaS
// Re-apply the RLS information:
psql --single-transaction --set=ON_ERROR_STOP=on -f mydb.rls.sql
// Bonus step:
git commit mydb.rls.sql -m "Latest RLS for my database"
--
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2025-04-26 20:32:38 | Re: PGDump question/issue |
Previous Message | Ayden Gera | 2025-04-26 10:19:39 | Re: PGDump question/issue |