In other words, being more like the SQL standard is probably good, but breaking compatibility is bad. You've technically avoided a *backward* compatibility break by deciding that functions and procedures can work differently from each other, but that just moves the problem around. Now instead of being unhappy that existing code is broken, people are unhappy that the new thing doesn't work like the existing thing. That may be the lesser of evils, but it's still pretty evil. People are not being unreasonable to want to call some code stored on the server without having to worry about whether that code is in a box labelled PROCEDURE or a box labelled FUNCTION.
Reading this from the (JDBC) drivers perspective, which is probably a fairly popular one,
We now have a standard that we can't really support. Either the driver will have to support
the new PROCEDURE with the {call } mechanism or stay with the existing FUNCTIONS.
This puts the drivers in a no win situation.
This probably should have been discussed in more detail before this got committed, but I guess that's water under the bridge at this point. Nevertheless, I predict that this is going to be an ongoing source of pain for a long time to come.
Undoubtedly.. surely the opportunity to do something about this has not passed as this has not been
From:
Andres Freund Date: Subject:
Re: 10.5 but not 10.4: backend startup during reindex system: couldnot read block 0 in file "base/16400/..": read only 0 of 8192 bytes
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
