2014-08-12 15:09 GMT+02:00 Fabien COELHO <coe...@cri.ensmp.fr>:
>
> Hello,
>
>
> - I would suggest to avoid "continue" within a loop so that the code is
>>> simpler to understand, at least for me.
>>>
>>
>> I personally find the code easier to read with the continue.
>>
>
> Hmmm. I had to read the code to check it, and I did it twice. The point is
> that there is 3 exit points instead of 1 in the block, which is not in
> itself very bad, but:
>
> for(...) {
> if (ccc)
> xxx;
> ...
> foo++;
> }
>
> It looks like "foo++" is always executed, and you have to notice that xxx
> a few lines above is a continue to realise that it is only when ccc is
> false. This is also disconcerting if it happens to be the "rare" case, i.e.
> here most of the time the char is not '%', so most of the time foo is not
> incremented, although it is a the highest level. Also the code with
> continue does not really put forward that what is counted is '%' followed
> by a non '%'. Note that the corresponding execution code
> (pgplsql/src/pl_exec.c) uses one continue to get rid of the second '%',
> which is quite defendable in that case as it is a kind of exception, but
> the main condition remains a simple if block. Final argument, the
> structured version is shorter than the unstructured version, with just the
> two continues removed, and one negation also removed.
>
>
> to also turn the ereport()s into elog()s since the user should never see
>> them.
>>
>
> I'm not sure why elog is better than ereport in that case: ISTM that it is
> an error worth reporting if it ever happens, say there is another syntax
> added later on which is not caught for some reason by the compile-time
> check, so I would not change it.
>
>
one note: this patch can enforce a compatibility issues - a partially
broken functions, where some badly written RAISE statements was executed
newer.
I am not against this patch, but it should be in extra check probably ?? Or
we have to documented it as potential compatibility issue
Regards
Pavel
> --
> Fabien.
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
