From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: shared session variables |
Date: | 2012-08-31 18:05:08 |
Message-ID: | m28vcvuecr.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-08-31 18:23:28 | Re: _USE_32BIT_TIME_T Patch |
Previous Message | Fujii Masao | 2012-08-31 17:32:16 | Re: Cascading replication and recovery_target_timeline='latest' |