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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: final patch - plpgsql: for-in-array
Date: 2010-11-24 15:33:02
Message-ID: 18771.1290612782@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Right, that was my impression, too. But, I think this may be partly a
> case of people talking past each other. My impression of this
> conversation was a repetition of this sequence:

> A: This syntax is bad.
> B: But it's way faster!

> ...which makes no sense. However, what I now think is going on here
> is that there are really two separate things that are wished for here
> - a more compact syntax, and a performance improvement. And taken
> separately, I agree with both of those desires. PL/pgsql is an
> incredibly clunky language syntactically, and it's also slow. A patch
> that improves either one of those things has value, whether or not it
> also does the other one.

I understand the desire for nicer syntax, in the abstract. I'm just
unimpressed by this particular change, mainly because I'm afraid that
it will make syntax-error behaviors worse and foreclose future options
for other changes to FOR. If it were necessary to change the syntax
to get the performance benefit, I might think that on balance we should
do so; but it isn't.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-24 15:34:52 Re: Suggested "easy" TODO: pg_dump --from-list
Previous Message Tom Lane 2010-11-24 15:25:42 Re: profiling connection overhead