Re: REVIEW: WIP: plpgsql - foreach in
От | Pavel Stehule |
---|---|
Тема | Re: REVIEW: WIP: plpgsql - foreach in |
Дата | |
Msg-id | AANLkTimTkMuBebcxMROYWzGjX03qR2fGwwkdvvGeZoVt@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: REVIEW: WIP: plpgsql - foreach in (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: REVIEW: WIP: plpgsql - foreach in
|
Список | 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 по дате отправления: