Skip site navigation (1) Skip section navigation (2)

Re: patch: shared session variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
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:27:08
Message-ID: CAFj8pRDEZ-5+_9M+cvnwt8ALWy_edodxLXbA4Mt-3dj8y9JCuw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2012/8/31 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
> 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?

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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-08-31 19:36:34
Subject: Re: _USE_32BIT_TIME_T Patch
Previous:From: Andrew DunstanDate: 2012-08-31 18:23:28
Subject: Re: _USE_32BIT_TIME_T Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group