>
>
> 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 ?
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
