Alvaro Herrera writes:
> Tom Lane wrote:
>> I really think we should stick with the macro implementation, unless
>> somebody wants to do some actual investigation to prove that a
>> function implementation imposes negligible cost.
> I don't really care too much about the macro-or-function side of
Tom Lane wrote:
> I really think we should stick with the macro implementation, unless
> somebody wants to do some actual investigation to prove that a
> function implementation imposes negligible cost. I'm not prepared
> to just assume that, especially not after the work I just did on
> plpgsql
On Wed, Jan 3, 2018 at 1:53 PM, Tom Lane wrote:
> I thought about this a bit harder and realized that if we make it
> a function, we will have to pass "rc" by reference since the function
> needs to change it in some cases. That might have no impact if the
> compiler is smart enough, but I expect
Robert Haas writes:
> On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane wrote:
>> It could be converted into a function returning bool, a la
>> if (!loop_rc_processing(...))
>> break;
> I prefer writing this sort of thing using a function call and
> dispatching on the return value, as
On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Darafei "Komяpa" Praliaskouski wrote:
>>> - can this macro become a function?
>
>> The "exit_action" argument makes it tough. It can probably be done --
>> it seems to require contorting the one callsite that uses "goto
Alvaro Herrera writes:
> Tom Lane wrote:
>> However, while I was doing that, it seemed like the tests I was adding
>> were mighty repetitive, as many of them were just exactly the same thing
>> adjusted for a different kind of loop statement. And so I began to wonder
>> why it was that we had fiv
Alvaro Herrera writes:
> Darafei "Komяpa" Praliaskouski wrote:
>> - can this macro become a function?
> The "exit_action" argument makes it tough. It can probably be done --
> it seems to require contorting the one callsite that uses "goto" though.
It could be converted into a function returnin
Darafei "Komяpa" Praliaskouski wrote:
> - how do currently existing coverage tools display coverage for such a
> large macro?
>
> I expect DEFINE's to be treated as comments.
It is, but then it is counted in the callsite where each branch is
displayed separately. So in
https://coverage.postgre
Hello!
> However, while I was doing that, it seemed like the tests I was adding
> were mighty repetitive, as many of them were just exactly the same thing
> adjusted for a different kind of loop statement. And so I began to wonder
> why it was that we had five copies of the RC_FOO management logi
Tom Lane wrote:
> However, while I was doing that, it seemed like the tests I was adding
> were mighty repetitive, as many of them were just exactly the same thing
> adjusted for a different kind of loop statement. And so I began to wonder
> why it was that we had five copies of the RC_FOO manage
2017-12-30 22:46 GMT+01:00 Tom Lane :
> While I've been fooling around with plpgsql, I've been paying close
> attention to code coverage reports to make sure that the regression tests
> exercise all that new code. It started to bug me that there were some
> serious gaps in the test coverage for e
11 matches
Mail list logo
