Re: Stored procedures and out parameters
| От | Dave Cramer |
|---|---|
| Тема | Re: Stored procedures and out parameters |
| Дата | |
| Msg-id | CADK3HHJH-BT93BgYt1_3kCKPysxCNYWVaaQS6GfVWVkDqJNpmg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Stored procedures and out parameters (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Stored procedures and out parameters
|
| Список | 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 по дате отправления: