The library design is based on guessing the suitable type by the shape of the parameter. This means there is a chance of an incorrect representation of the parameter. Here are a couple of examples:
- Invalid SQL generated for JSON fragment · Issue #21 · fuelen/ecto_dev_logger · GitHub
- 16 character string converted to UUID · Issue #9 · fuelen/ecto_dev_logger · GitHub (It is possible to fix this by adding some special conditions for UUIDs, and I think I’ll do this eventually
)
To get rid of guessing, we need more low-level information about types, like Postgrex.Extensions.UUID, Postgrex.Extensions.JSONB, etc. But even Ecto doesn’t operate these types as the modules mentioned above are not public
https://github.com/elixir-ecto/postgrex/blob/c0eb94e3d3538bd52a3a8334ad66d7c243583fea/lib/postgrex/extensions/uuid.ex#L2
Moreover, not all database adapters even have similar type representation.
Here is a related discussion https://groups.google.com/g/elixir-ecto/c/5AwUoaEuq4E/m/J9Kbr9FOBAAJ?pli=1
In summary, to have this feature in Ecto, it probably should be implemented on the DB adapter level.
