Re: Stored procedures and out parameters - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Stored procedures and out parameters
Date
Msg-id CADK3HHJH-BT93BgYt1_3kCKPysxCNYWVaaQS6GfVWVkDqJNpmg@mail.gmail.com
Whole thread Raw
In response to Re: Stored procedures and out parameters  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Stored procedures and out parameters
List pgsql-hackers

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
officially released ?


 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Use C99 designated initializers for some structs
Next
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