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
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 existing code in pl_exec.c.
One thing I noticed
12 matches
Mail list logo
