Re: PL/pgSQL support to define multi variables once - Mailing list pgsql-hackers

From David Johnston
Subject Re: PL/pgSQL support to define multi variables once
Date
Msg-id CAKFQuwb5b2H-RxF0+3nxLMjJq3Rz1kojMjRSBhKUt3xW9N3eag@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL support to define multi variables once  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/pgSQL support to define multi variables once  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jun 13, 2014 at 11:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David G Johnston <david.g.johnston@gmail.com> writes:
> Tom Lane-2 wrote
>> At the very least I think we should stay away from this syntax until
>> the SQL committee understand it better than they evidently do today.
>> I don't want to implement it and then get caught by a future
>> clarification that resolves the issue differently than we did.

> Its not quite as unclear as you make it out to be:

Yes it is.


​Not withstanding the decision making of the SQL committee I was rejecting as inconsistent:

SET random_1 = 0;
SET random_2 = 0;
SET random_3 = random(1234); ​

The ambiguity regarding re-execute or copy still remains.
 
That's not the reading I want, and it's not the reading you want either,
but there is nothing in the existing text that justifies single
evaluation.  So I think we'd be well advised to sit on our hands until
the committee clarifies that.  It's not like there is some urgent reason
to have this feature.



Agreed.


I don't suppose there is any support or prohibition on the :

one,two,three integer := generate_series(1,3)​;

interpretation...not that I can actually come up with a good use case that wouldn't be better implemented via a loop in the main body.

David J.


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL support to define multi variables once
Next
From: David G Johnston
Date:
Subject: Re: Audit of logout