2012/8/31 Dimitri Fontaine <dimi...@2ndquadrant.fr>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >>> Pavel, you didn't say what you think about the WITH FUNCTION proposal? >> >> I don't like it - this proposal is too "lispish" - it is not SQL > > We're not doing lambda here, only extending a facility that we rely on > today. The function would be named, for one. I don't know what you mean > by SQL being lispish here, and I can't imagine why it would be something > to avoid. > >>> And you didn't say how do you want to turn a utility statement into >>> something that is able to return a result set. >> >> if we support "real" procedures ala sybase procedures (MySQL, MSSQL..) >> - then we can return result with same mechanism - there are no >> significant difference between DO and CALL statements - you don't know >> what will be result type before you call it. > > Currently we don't have CALL, and we have DO which is not a query but a > utility statement. Are you proposing to implement CALL? What would be > the difference between making DO a query and having CALL?
defacto a CALL statement implementation can solve this issue. The core of this issue is an impossibility using parameters for utility statements. CALL and DO are utility statements - and if we can use parameters for CALL, then we can do it for DO too. CALL statement starts a predefined batch - inside this batch, you can do anything - can use COMMIT, ROLLBACK, SELECTs, ... DO is some batch with immediate start. Sure, there is relative significant between stored procedures implemented in popular RDBMS and although I don't like T-SQL too much, I like sybase concept of stored procedures - it is strong and very useful for maintaining tasks. Regards Pavel > > Regards, > -- > Dimitri Fontaine > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
