Hi,
I still haven't heard an explanation why you see a problem here.
On 2019-06-27 15:54:28 +0200, didier wrote:
> I searched the mailing list but found nothing. Any reason why
> TupleDescAttr is a macro and not a static inline?
It's present in branches that can't rely on static inlines being
p
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
Hi,
On June 13, 2019 11:08:15 AM PDT, didier 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
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 ?
didier writes:
> JIT slot_compile_deform assumes there's at least 'natts' in TupleDesc, eg
> /*
> * Iterate over each attribute that needs to be deformed, build code
> to
> * deform it.
> */
> for (attnum = 0; attnum < natts; attnum++)
> {
>
Hi,
JIT slot_compile_deform assumes there's at least 'natts' in TupleDesc, eg
/*
* Iterate over each attribute that needs to be deformed, build code to
* deform it.
*/
for (attnum = 0; attnum < natts; attnum++)
{
Form_pg_attribute
