On Tuesday, June 11, 2013, Pavel Stehule wrote:
> I don't believe there's any intent to ever have DO used for stored
> procedures. Not only are stored procedures deserving of their own
> top-level command (eg: CALL, as has been discussed before..), but I
> believe they would necessairly have different enough semantics that
> shoe-horning them into DO would end up breaking backwards compatibility.
In this moment, DO doesn't support any feature that is in conflict
with stored procedure functionality, because it is based on functions,
and then it have to have limited functionality
Let me re-state: I don't see DO, which is entirely function oriented today, ever being redefined as suddenly being stored procedures instead. Claiming that it wouldn't impact existing users of DO is a level of hand-waving that I just can't follow. If nothing else, it would certainly impact external language support.
If we're going to continue to hand-wave at this then I would argue that we'd be able to magically make DO .. RETURNING also happily work in "stored procedure" mode when the time comes without impacting users.
I'm done with this thread. For my part- we can and should extend DO to support RETURNING. DO RETURNING support is a big enough and useful enough addition that it can go in by itself. Attempting to feature-creep it to also cover stored procedures will simply end up killing it unfairly and will not move us forward at all.
We should also have stored procedures. Until there's an actual patch for stored procedures which has some real conflict with DO RETURNING, I don't see it as being relevant.
I look forward to patches for both.
Thanks,
Stephen
