Hi, On 9/2/18 4:32 PM, Robert Haas wrote: > On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer <p...@fastcrypt.com> wrote: >> 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. > > I understand and I agree. > >> Undoubtedly.. surely the opportunity to do something about this has not >> passed as this has not been >> officially released ? > > I agree with that, too, but I can't make other people do things they > don't want to do, and then there's the question of time. On the basis > of previous experience, there is going to be little appetite for > holding up the release to address this issue no matter how badly > busted it is. Ultimately, it's the RMT that must decide what to do in > cases like this. I have confidence that they are watching this > thread, but I don't know what they will decide to do about it. >
First, I want everyone to know that the RMT took this very seriously and took time collect feedback and consult with as many people as we could in order to make the best possible decision for v11 and ensure that any decision we made did not hinder any future implementation for stored procedures nor introduced something that would break backwards compatibility. Ultimately, the decision came down to one of four options: #1: Do nothing and remove the open item #2: Introduce nonstandard syntax for calling functions / procedures #3: Have CALL support both functions & procedures (or SELECT support calling functions) #4: Disable CALL The RMT has decided to go with option #1 and will be removing the open item for the PostgreSQL 11 release. We understand that this will impact how drivers such as JDBC & ODBC will support stored procedures for v11 and this was a detail we took into great consideration. Through our discussions, we also know that there are other ways that users can call stored procedures, and understand that for people who are used to programming with the JDBC/ODBC interfaces that this is considered a "workaround." We hope that the community can continue to improve the stored procedure functionality for v12 and that there will be continued work on CALL such that we can make it easier for our driver maintainers to make stored procedures more easily available for our users. Personally, I know this is a feature that many people are very excited for, and I look forward to future work that will continue to improve upon what we are releasing in v11. While some of you may be disappointed that we are removing the open item, we do hope this frees the group up to discuss, plan, and implement a solution for v12 without the pressure of a release deadline. Sincerely, Jonathan
signature.asc
Description: OpenPGP digital signature