Handle a scenario when the return type of a function changes.

[jasiek]

Suppose you have a function whose return type is TABLE(account_id text, balance numeric). You change the function to return TABLE(bank_account text, balance numeric). Changing the return type of a function is not permitted in PG, one needs to drop and create it from scratch.

IMO, this should be detected and reflected in the generated migrations.

Thoughts?

[olirice]

There was a similar request for views in #5

First trying a replace and failing onto a drop + create would also work in this case if the function has no dependent entities

What do you think about that?

[jasiek]

Yes, I think this makes sense.

I didn't think at all about dependents, or rather I only thought about other dependent functions whose dependency seems to be resolved at run-time.

If there are dependents, then the DROP will fail, which sounds like a sensible way of failing.

[olirice]

If there are dependents, then the DROP will fail, which sounds like a sensible way of failing.

That would work if the dependency is e.g. a view, but if a second function refers to the first (the one being updated) it would succeed but cause runtime errors later because postgres stores function bodies as text and does not check them for dependencies when the schema updates.

For that reason I don't think the same solution as views will be appropriate.

Closing, but feel free to comment if you have more thoughts