Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
> > 1. You use a do {...} while(0) construct to wrap the whole thing. This
> > actually makes it impossible to write code that does a try/catch within
> > a loop that contains code surrounding it since a continue or break will
> > the
Tom Lane wrote:
Perhaps, but what about everyone's editors' autoindent logic?
I'd have preferred not to have the "();" decoration too, but it is
really not worth the pain.
I guess you have a point. Ok, I'll live with it.
Regards,
Thomas Hallgren
---(end of broadcast)
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This isn't really open for debate, because if we don't put that there,
>> pg_indent will go nuts.
>>
> I'm not familiar with pg_indent but my guess is that the first and
> foremost motivation for its existence is code readability an
Tom Lane wrote:
A continue or break exiting the construct would do the wrong thing
anyway, so I don't see that removing the do{} is very helpful. The
point of having it is to make sure that a try/end try block is
syntactically like a statement, rather than like a { ... } construct.
Yes, a continue
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> 1. You use a do {...} while(0) construct to wrap the whole thing. This
> actually makes it impossible to write code that does a try/catch within
> a loop that contains code surrounding it since a continue or break will
> then end up in the wrong plac
As I was integrating the new PG_TRY/PG_CATCH/PG_END_TRY macros I
discovered a couple of minor issues.
1. You use a do {...} while(0) construct to wrap the whole thing. This
actually makes it impossible to write code that does a try/catch within
a loop that contains code surrounding it since a c
