Re: final patch - plpgsql: for-in-array
От | Cédric Villemain |
---|---|
Тема | Re: final patch - plpgsql: for-in-array |
Дата | |
Msg-id | AANLkTin1V_JcmPLHLxnt-TgasfJdDQabSw4McRjqZS8o@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: final patch - plpgsql: for-in-array (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: final patch - plpgsql: for-in-array
(Robert Haas <robertmhaas@gmail.com>)
Re: final patch - plpgsql: for-in-array (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: