Re: REVIEW: WIP: plpgsql - foreach in

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVIEW: WIP: plpgsql - foreach in
Date: 2011-01-29 13:05:27
Message-ID: AANLkTimTkMuBebcxMROYWzGjX03qR2fGwwkdvvGeZoVt@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/1/29 Stephen Frost <sfrost(at)snowman(dot)net>:
> * Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
>> I don't see a problem too, but we didn't find a compromise with this
>> syntax, so I left it. It is true, so current implementation of FOR
>> stmt is really baroque and next argument is a compatibility with
>> PL/SQL. My idea is so FOR stmt will be a compatible with PL/SQL
>> original, and FOREACH can be a platform for PostgreSQL specific code.
>
> I see that as an absolutely horrible idea.  If you want that, it should
> be "PGFOR" or something, but I don't buy off on the idea that we should
> invent new top-level PG-specific keywords for PL/PgSQL because they're
> PG-specific.  I also don't see why FOR wouldn't still be as compatible
> w/ PL/SQL as it was before (except in the possible case where someone
> actually has 'ARRAY' there already, but I'm pretty sure we can convince
> ourselves that such a construct is very unlikely to appear in the wild).

you can rename it as some different than original ADA concept, if you
like. It is similar like FORALL cycle from PL/SQL. Native ADA's FOR
cycle doesn't know iteration over array.

You have a similar opinion like me about design this statement. But
there are others with strong negative opinion. For someone ARRAY ARRAY
should be a problem. So FOREACH is third way - more, it increase a
possibility for enhancing plpgsql in future.

>
> I certainly don't think we should *not* do something under FOR because
> we're worried that people might use it and then get unhappy when they
> port that code to PL/SQL.

PL/pgSQL is some like Frankenstein :) Fast, functional but sometime
strange - more stranger than origin. I don't think so it necessary to
do live harder for people who have to work with both databases.

the main issue was a maintainability of more complex FOR statement.

Pavel

>
>        Thanks,
>
>                Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1EBDwACgkQrzgMPqB3kijDLQCcCpb15jTvU3rIdh5j9ipaqq+X
> G+wAn2WrxDkgArf5xHxt4bi8EpE0HVFP
> =Fx/8
> -----END PGP SIGNATURE-----
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2011-01-29 13:09:33 Re: REVIEW: WIP: plpgsql - foreach in
Previous Message Stephen Frost 2011-01-29 13:02:58 Re: REVIEW: WIP: plpgsql - foreach in