Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id 3159057.1607376752@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> The TypeParamBool stuff here is ok. Basically LLVM uses a '1bit' integer
> to represent booleans in the IR. But when it comes to storing such a
> value in memory, it uses 1 byte, for obvious reasons. Hence the two
> types.

Cool, thanks for taking a look.

> I think it'd be a better to rely on the backend's definition of
> ExecEvalBoolSubroutine etc. For the functions implementing expression
> steps I've found that far easier to work with over time (because you can
> get LLVM to issue type mismatch errors when the signature changes,
> instead of seeing compile failures).

I'm a little unclear on what you mean here?  There wasn't such a
thing as ExecEvalBoolSubroutine until I added it in this patch.

> I've attached a prototype conversion for two other such places. Which
> immediately pointed to a bug. And one harmless issue (using a pointer to
> size_t instead of ExprEvalOp* to represent the 'op' parameter), which
> you promptly copied...
> If I pushed a slightly cleaned up version of that, it should be fairly
> easy to adapt your code to it, I think?

Sure.  I just copied the existing code for EEOP_PARAM_CALLBACK;
if that changes, I'll just copy the new code.

What did you think of the idea of merging EEOP_SBSREF_OLD / ASSIGN / FETCH
into a single step type distinguished only by the callback function?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: David Zhang
Date:
Subject: Re: Add table access method as an option to pgbench