Re: PL/PgSQL: RAISE and the number of parameters

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: PL/PgSQL: RAISE and the number of parameters
Дата
Msg-id alpine.DEB.2.10.1409021028060.19169@sto
обсуждение исходный текст
Ответ на Re: PL/PgSQL: RAISE and the number of parameters  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: PL/PgSQL: RAISE and the number of parameters  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Hello Marko,

> I've changed the loop slightly.  Do you find this more readable than the way 
> the loop was previously written?

It is 50% better:-)

It is no big deal, but I still fail to find the remaining continue as 
usefull in this case. If you remove the "continue" line and invert the 
condition, it works exactly the same, so it is just one useless 
instruction within that loop. From a logical point of view the loop is 
looking for '%' and then check whether the next char is '%' or not, so the 
straightforward code helps my understanding as it does exactly that, and 
the continue is just an hindrance to comprehension.

Note that I would buy it if it helped avoid indenting further a 
significant portion of complex code, but this is not the case here.

> [doc] I've incorporated these changes into this version of the patch, 
> with small changes.

Ok.

> With elog(ERROR, ..) it's still reported, but the user isn't fooled into 
> thinking that the error is to be expected, and hopefully we would see a bug 
> report.  If it's impossible to tell the two errors apart, we might have 
> subtly broken code carried around for who knows how long.

Ok.

In that case, it would make sense to keep distinct wordings of both 
exceptions in the execution code, so that they also can be set apart,
i.e. keep the "too many/few" somewhere in the error?

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Xiaoyulei
Дата:
Сообщение: why after increase the hash table partitions, TPMC decrease
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL 2