4 ms·
It isn't. But that's easily mitigated with temp tables, ephemeral database and COPY etc. Upstream can easily f-up and (accidentally) delete production data if
by berkes 3y ago
It isn't. But that's easily mitigated with temp tables, ephemeral database and COPY etc.
Upstream can easily f-up and (accidentally) delete production data if you do this on a live db. Which is why PostgreSQL and nearly all other DBS have a miriad of tools to solve this by not doing it directly on a production database
- wefarrell 3y agoMaybe I'm missing something but I don't see how it's possible for a COPY statement alone to remove existing data.
- LgWoodenBadger 3y agoIf in the regular scenario you load 10000 rows of new data and delete the old then it’s fine. What if someone screws up the zip and instead of 10000 today, it’s only 10?
- aidos 3y agoI had this last week, but instead it was a 3rd party api and their service started returning null instead of true for the has_more property beyond the second page of results. In either the solution is probably to check rough counts and error if not reasonable.
- camgunz 3y agoI think generally don't replace the prod db until the new one passes tests.