Hi,
I searched the mailing list but found nothing. Any reason why
TupleDescAttr is a macro and not a static inline?
Rather than adding an Assert attached POC replace TupleDescAttr macro
by a static inline function with AssertArg.
It:
- Factorize Assert.
- Trigger an Assert in JIT_deform if natts is wrong.
- Currently In HEAD
src/backend/access/common/tupdesc.c:TupleDescCopyEntry() compiler can
optimize out AssertArg(PointerIsValid(...)), no idea
if compiling with both cassert and -O2 make sense though).
- Remove two UB in memcpy when natts is zero.
Note:
Comment line 1480 in ../contrib/tablefunc/tablefunc.c is wrong it's
the fourth column.
Regards
Didier
On Thu, Jun 13, 2019 at 8:35 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On June 13, 2019 11:08:15 AM PDT, didier <did447@gmail.com> wrote:
> >Extensions can do it, timescaledb in this case with:
> >INSERT INTO ... RETURNING *;
> >
> >Or replacing the test in llvm_compile_expr with an Assert in
> >slot_compile_deform ?
>
> In that case we ought to never generate a deform expression step - core code doesn't afair. That's only done I'd
there'sactually something to deform. I'm fine with adding an assert tough
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.