Question : Can we have tables in destination but delete from source

[bheemvennapureddy]

Use case : we want to have an option to delete source presence for a table which is deprecated but wanna keep in the destination for compliance reason or data validation reasons in case if that comes across.

Can we support some thing like that ?

[Navbryce]

I might be a bit confused with this one. Could you give an example of the diff of your schema, the hypothetical command to plan your migrations, and the expected generated SQL? Thanks!

[bheemvennapureddy]

You can probably ignore this

Use case: Lets say there is a table identity and we move away from that table to the user table and we still wanna keep the identity table in the destination but remove from the source code we don't want that table to be dropped by pg-schema-diff

[bokidonev]

I can see this was closed, but there is a real world scenario where we would need to ignore separate objects (tables, functions, sequences), not just whole schemas. Apart from the scenarios mentioned earlier in the thread, there are librarires that create their own database objects on application startup (Hangfire, MassTransit...), and pg-schema-diff fails because it wants to drop them as we don't have them in the source code (and we shouldn't really).

As you suggested in another issue, for now what we can do is:

• pg-dump --schema-only, and put them in the source
• put them in a separate schema and ignore that schema

But I think it would be really nice if I can tell pg-schema-diff: ignore these and these objects.

[bplunkett-stripe]

@bokidonev It is totally possible to ignore schema-level objects. What are you trying to ignore (tables, indexes, triggers, etc)? We'd probably have to implement it an object-to-object basis

[bokidonev]

Thanks for reopening this. For my scenario, I'm trying to ignore tables, sequences and functions.

[bplunkett-stripe]

Okay cool, that makes sense. I'll see if I can make something moderately generic to do this across most schema objects