Re: REVIEW: WIP: plpgsql - foreach in - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: REVIEW: WIP: plpgsql - foreach in
Date
Msg-id AANLkTimTkMuBebcxMROYWzGjX03qR2fGwwkdvvGeZoVt@mail.gmail.com
Whole thread Raw
In response to Re: REVIEW: WIP: plpgsql - foreach in  (Stephen Frost <sfrost@snowman.net>)
Responses Re: REVIEW: WIP: plpgsql - foreach in
List pgsql-hackers
2011/1/29 Stephen Frost <sfrost@snowman.net>:
> * Pavel Stehule (pavel.stehule@gmail.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-----
>
>


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: REVIEW: WIP: plpgsql - foreach in
Next
From: Stephen Frost
Date:
Subject: Re: REVIEW: WIP: plpgsql - foreach in