On Fri, 25 Mar 2022 at 17:42, Alvaro Herrera wrote:
> On 2022-Mar-24, Japin Li wrote:
>
>> Thanks for your detail explaination. I find bottomup_sort_and_shrink_cmp()
>> has smilar code
>
> ... except that bottomup_sort_and_shrink_cmp never handles the case of
> the two structs being exactly ide
On 2022-Mar-24, Japin Li wrote:
> Thanks for your detail explaination. I find bottomup_sort_and_shrink_cmp()
> has smilar code
... except that bottomup_sort_and_shrink_cmp never handles the case of
the two structs being exactly identical, so I don't think this is a
great counter-example.
> IIUC
On 2022-Mar-24, Peter Eisentraut wrote:
> But no compiler is stupid enough not to understand that
>
> foo()
> {
> if (something)
> return this;
> else
> return that;
> }
>
> always reaches a return.
We have a number of examples of this pattern, so I guess it must be
true
On 24.03.22 15:32, Alvaro Herrera wrote:
+static inline Datum
+heap_getattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, bool *isnull)
+{
+ if (attnum > 0)
+ {
+ if (attnum > (int) HeapTupleHeaderGetNatts(tup->t_data))
+ return getmissingattr(tup
On 24.03.22 13:09, Michael Paquier wrote:
Hmm. I think that you'd better add a return at the end of each
function? Some compilers are dumb in detecting that all the code
paths return (aka recent d0083c1) and could generate warnings, even if
things are coded to return all the time, like in your
On Thu, 24 Mar 2022 at 22:32, Alvaro Herrera wrote:
> On 2022-Mar-24, Japin Li wrote:
>
>> I want to know why we do not use the following style?
>>
>> +static inline Datum
>> +heap_getattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, bool *isnull)
>> +{
>> +if (attnum > 0)
>> +{
>> +
On 2022-Mar-24, Japin Li wrote:
> I want to know why we do not use the following style?
>
> +static inline Datum
> +heap_getattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, bool *isnull)
> +{
> + if (attnum > 0)
> + {
> + if (attnum > (int) HeapTupleHeaderGetNatts(tup->t_d
On Thu, 24 Mar 2022 at 21:26, Alvaro Herrera wrote:
> On 2022-Mar-24, Michael Paquier wrote:
>
>> Hmm. I think that you'd better add a return at the end of each
>> function? Some compilers are dumb in detecting that all the code
>> paths return (aka recent d0083c1) and could generate warnings,
On 2022-Mar-24, Michael Paquier wrote:
> Hmm. I think that you'd better add a return at the end of each
> function? Some compilers are dumb in detecting that all the code
> paths return (aka recent d0083c1) and could generate warnings, even if
> things are coded to return all the time, like in
On Thu, Mar 24, 2022 at 11:21:07AM +0100, Alvaro Herrera wrote:
> This patch should silence some recent Coverity (false positive)
> complaints about assertions contained in these macros.
The logic looks fine. Good idea to get rid of DISABLE_COMPLEX_MACRO.
> Portability testing at:
> https://cirr
This patch should silence some recent Coverity (false positive)
complaints about assertions contained in these macros.
Portability testing at:
https://cirrus-ci.com/github/alvherre/postgres/macros-to-inlinefuncs
Intend to push later today, unless something ugly happens.
--
Álvaro Herrera
11 matches
Mail list logo
