Re: pgindent vs try/catch
От | Gaetano Mendola |
---|---|
Тема | Re: pgindent vs try/catch |
Дата | |
Msg-id | 4144A5DE.1090608@bigfoot.com обсуждение исходный текст |
Ответ на | Re: pgindent vs try/catch ("Andrew Dunstan" <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan wrote: > Tom Lane said: > >>I'm fairly displeased with what pgindent has done to single-line PG_TRY >>constructs, as in this example from pl_exec.c: >> >>*************** exec_stmt_block(PLpgSQL_execstate * esta >>*** 911,922 **** >> SPI_result_code_string(xrc)); >> >> PG_TRY(); >>! { >>! rc = exec_stmts(estate, block->body); >>! } >> PG_CATCH(); >> { >>! ErrorData *edata; >> PLpgSQL_exceptions *exceptions; >> int j; >> >>--- 912,921 ---- >> SPI_result_code_string(xrc)); >> >> PG_TRY(); >>! rc = exec_stmts(estate, block->body); >> PG_CATCH(); >> { >>! ErrorData *edata; >> PLpgSQL_exceptions *exceptions; >> int j; >> >>*************** exec_stmt_block(PLpgSQL_execstate * esta >> >>On the whole I'd prefer that pgindent not suppress "unnecessary" >>brace pairs at all. > > > > I had that argument a while ago with Bruce and lost :-) . It does horrible > things to if/else constructs too. The workaround is to put a comment in the > block. On the whole I agree with you, though. If I put braces in my program > it's for a reason, and the indenter shouldn't think it knows better than me. Well I'm not exactly a C coder, I'm a C++ one and it's quite common use the extra scope in order to reduce the automatic variable life, I don't know how much the extra scope are used in the C world, however remove an "extra scope" like that is not only "horrible", is *wrong* and can be cause of future pain: foo ( int a ) { ... { int a; } // use the formal parameter } if the extra scope is removed the local variable "shadow" the formal parameter. Some compilers do not warning you, IIRC the Digital had this funny omission, ( however you can miss the warning ) and hours of debugging are behind the corner. I hope that Bruce change his mind... Regards Gaetano Mendola
В списке pgsql-hackers по дате отправления: