2010/11/23 Robert Haas <robertmh...@gmail.com>: > On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
