Proposal: Being able to pass arbitrary options to underlying dump cmd

[Milan Sedivy]

Hi, 

maybe I missed something obvious in the codebase/documentation, so please forgive if this is implemented and possible. I'm still relatively new to elixir and the ecosystem and learning on the fly.

However looking at the way ecto.dump is implemented, the caller is limited when it comes to passing additional options to ecto.dump. Without rewriting the code this forces the caller to either completely write his own task from scratch or write his own scripts that process the code after the task has finished, leading to possible problems that could've been avoided if the user could pass more options.

In my specific case (I'm using postgres) I would like to call the underlying pg_dump with --clean and --if-exists.

Looking at pg_dump that gets called by structure_dump most options are hardcoded:

path = config[:dump_path] || Path.join(default, "structure.sql")   

prefixes = config[:dump_prefixes] ||

non_prefix_args = ["--file", path, "--schema-only", "--no-acl", "--no-owner"]    

args = Enum.reduce(prefixes, non_prefix_args, fn prefix, acc ->  ["-n", prefix | acc]   end)

a minimal fix would be to add something like

additional_opts = config[:additional_opts] (this could be just a string with all the commands one person wants to pass) and append it to args leaving the caller to "better know what he's doing". 

Thoughts?

Cheers

[Syed Rohaan Alam]

Hi Milan,

Thanks for sharing the detailed explanation — it really helped clarify
your use case and the limitation you’re running into with ecto.dump.

I’ve looked into it, but I think what you’re asking for is actually
outside the scope of my project (ecto_database_first).

My tool is intentionally focused on a database-first approach, where
the database already exists (often designed and maintained by DB
engineers or already well-structured in production/legacy systems),
and the goal is to generate Ecto schemas from that existing state.

Because of that, it doesn’t interact with or extend pg_dump,
structure_dump, or Ecto’s dumping pipeline. It operates at a higher
level through database introspection rather than dump generation.

Your suggestion around extending pg_dump options like --clean and
--if-exists makes sense in the context of Ecto’s dump system, but that
belongs to a different layer of the ecosystem than what this project
is designed for.

That said, if you’re genuinely stuck on something important in your
workflow, feel free to reach out to me directly via email — I’d be
happy to help where I can. I just won’t be able to incorporate this
change into the current project scope.

Thanks again for taking the time to write such a thoughtful message.

Best regards,
Rohaan

> --
> You received this message because you are subscribed to the Google Groups "elixir-ecto" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-ecto...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/elixir-ecto/e6b3c246-7aaa-4d2a-b242-8718589d2d2cn%40googlegroups.com.