-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle a scenario when the return type of a function changes. #7
Comments
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? |
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. |
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 |
Suppose you have a function whose return type is
TABLE(account_id text, balance numeric)
. You change the function to returnTABLE(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?
The text was updated successfully, but these errors were encountered: