perseas / Pyrseas

Provides utilities for Postgres database schema versioning.
https://perseas.github.io/
BSD 3-Clause "New" or "Revised" License
395 stars 67 forks source link

Casts depending on extensions are not excluded #209

Open declaresub opened 4 years ago

declaresub commented 4 years ago

Casts depending on extensions are not excluded. So sql generated for a database that should drop an extension like hstore looks like

BEGIN; DROP EXTENSION hstore; DROP CAST (public.hstore AS jsonb); DROP CAST (public.hstore AS json); DROP CAST (text[] AS public.hstore); COMMIT;

Then once the extension is dropped, the next drop cast statement fails

This could be resolved, I think, either by updating the statement in Cast.query, or by emitting DROP CAST IF EXISTS statements.

jmafc commented 4 years ago

I think maybe the way to fix this is in Cast.get_implied_deps or in Extension.get_implied_deps. @dvarrazzo your input would be appreciated.

dvarrazzo commented 4 years ago

I think the treatment of the objects inside extensions, and the relative dependencies, can use some love.

Pretty much all the queries to read types from the system tables have grown some clause such as

              AND p.oid NOT IN (
                  SELECT objid FROM pg_depend WHERE deptype = 'e'

to avoid dealing with objects belonging to an extension. This results in the dependencies to these objects to be missed, and as a consequence missing the fact the object depend on the extension. We get by probably by creating the extension before pretty much everything else, but that doesn't feel correct.

Probably we should do something like:

Now, I don't know exactly the problem behind this wrong drop order, but I feel like that the missing information of the dependency from the cast to the function is a cause. That dependency should be returned by Cast.get_implied_deps (it is probably ignored because the function, being part of an extension, is discarded) and transformed into a dependency of the cast on the extension.

jmafc commented 4 years ago

I knew I could depend (pun intended) on you for a thoughtful response. Yes, unfortunately, Pyrseas suffers from some premature optimizations (after all, it was going to only deal with simple stuff like schemas/tables/columns and maybe functions and not all the rest of the PG objects). Loading all objects would also be applicable for #185. Alas, I haven't been using it much lately, so aside from thanking you Daniele, I don't what else to say.