Hi,
On 9/2/18 4:32 PM, Robert Haas wrote:
> On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer <pg@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