Re: support for MERGE - Mailing list pgsql-hackers

From Amit Langote
Subject Re: support for MERGE
Date
Msg-id CA+HiwqEHfKkYv48k8raHexstN96neXc6C7jTFgvCU5vcc5+yrg@mail.gmail.com
Whole thread Raw
In response to Re: support for MERGE  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Sun, Nov 14, 2021 at 12:23 AM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2021-Nov-13, Daniel Westermann wrote:
> > /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2  -I../../../src/include  -D_GNU_SOURCE
-I/usr/include/libxml2 -flto=thin -emit-llvm -c -o execMerge.bc execMerge.c 
> > execMerge.c:552:32: warning: if statement has empty body [-Wempty-body]
> >                                         RELKIND_PARTITIONED_TABLE);
> >                                                                   ^
> > execMerge.c:552:32: note: put the semicolon on a separate line to silence this warning
>
> Oh wow, this may be a pretty serious problem actually.  I think it
> represents a gap in testing.  Thanks for reporting.

Ah, thanks indeed.  It seems that I fat-fingered that semicolon in.
Though, it's not as serious as it would've been if I had instead
fat-fingered a `&& false` into that condition and not the semicolon.
;)

The only problem caused by the code block that follows the buggy if
statement unconditionally executing is wasted cycles.  Fortunately,
there's no correctness issue, because rootRelInfo is the same as the
input result relation in the cases where the latter is not partitioned
and there'd be no map to convert the tuple, so the block is basically
a no-op.   I was afraid about the case where the input relation is a
regular inheritance parent, though apparently we don't support MERGE
in that case to begin with.

--
Amit Langote
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Shinya Kato
Date:
Subject: Emit a warning if the extension's GUC is set incorrectly
Next
From: Michail Nikolaev
Date:
Subject: Re: Slow standby snapshot