Re: final patch - plpgsql: for-in-array

2010/11/23 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> ok, I can only recapitulate so this feature was proposed cca two
>> months ago, and minimally Tom and maybe you did agreement - with
>> request on syntax - do you remember? I am little bit tired so this
>> agreement was changed when I spent my time with this.
>
> I went back and reread the thread I believe you're speaking about.
> The first post is here:
>
> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01945.php

Here perhaps ? (or before)

http://archives.postgresql.org/pgsql-hackers/2010-09/msg01983.php

>
> I cannot find one single email on that thread where Tom or I or anyone
> else endorsed the syntax you've proposed here;

Nah, but you didn't disagree on the main idea, you just said : 'like
Tom I agree that syntax must be uptaded to something beter' , more or
less

> indeed, it and some
> other suggestions were roundly criticized.  You responded to that by
> saying that the arguments against it were all wrong, but no one other
> than you ever appeared to believe that.  There are a few emails on
> that thread where other people agreed that it would be nice, in
> theory, to have some syntax for this, but there is not one single
> email that I see saying that any syntax you proposed was a good one.
> If you read that thread and concluded that there was consensus to
> implement this syntax, you did not read it very carefully.

I think you (Robert) misunderstood dramatically what Pavel try to do.
Pavel did an excellent optimization work for a specific point. This
specific point looks crucial for me in the current behavior of
PostgreSQL[1]. AFAIS Pavel didn't want to implement a genious syntax,
but an optimization feature.

I don't care about syntax, I care with Tom explanation on that. but no more.

I care with the idea that this patch is just a quick way to cut the iceberg.
It is.
and ?

And we might do it better with more deep analysis and refactoring more
stuff, I agree...
Still this patch is interesting enought from perf point of view to not
trash it that quickly, IMO.

>
> If we had ELEMENT as a reserved keyword (which apparently it is in
> some versions of the SQL standard), maybe FOR ELEMENT wunk IN
> wunkarray... would be sufficiently unambiguous.  But it's not even an
> unreserved keyword right now, and I have a hard time thinking it would
> be worth reserving it just for this.

I am not aware of SQL spec precisely about that.
David, did your recent post about UNNEST stuff looks relevant in this
thread ? I mean can we elaborate something from your suggestion to
improve the situation of the current patch (and vice-versa) ?

[1] data compression in the array allow to insert billions of data for
a small size print. (I know it is not pure design, it is just pure
end-user very effective solution)

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support