Re: pg_stop_backup() v2 incorrectly marked as proretset - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stop_backup() v2 incorrectly marked as proretset
Date
Msg-id 3547212.1646345876@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stop_backup() v2 incorrectly marked as proretset  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 03/03/22 16:40, Tom Lane wrote:
>> The point is to make it clear that the macro isn't intended to affect
>> code outside the function.  Since C lacks block-scoped macros,
>> there's no other way to do that.

> Would the

>   Datum values[3];
>   bool   nulls[ lengthof(values) ];

> pattern be more notationally tidy?

Hm, I don't care for that particularly.

(1) It *looks* asymmetrical, even if it isn't.

(2) I think a lot of the benefit of the macro approach is to give a name
(and thereby some free documentation, assuming you take some care in
choosing the name) to what would otherwise be a very anonymous constant.

There's an actual practical problem with the anonymous-constant approach,
which is that if you have some other occurrence of "3" in the function,
it's very hard to tell if that's indeed an independent value or it's
something that should have been replaced by lengthof(values).
Now admittedly the same complaint can be made against the macro
approach, but at least there, you have some chance of the macro's name
providing enough docs to make it clear what the proper uses of it are.
(I'd suggest that that other "3" should also have been made a named
constant in many cases.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: pg_stop_backup() v2 incorrectly marked as proretset
Next
From: Jim Nasby
Date:
Subject: Re: Reducing power consumption on idle servers