I wrote:
> Agreed. I spent some time trying to do it better, with results
> shown at [1]. If we adopt that idea, then the executor's support
> for CaseTestExpr will go away, so there's little point in pursuing
> that half of the patch given here. However, I concluded that there's
> insufficient
Heikki Linnakangas writes:
> Huge +1 for cleaning up this abuse of caseValue_datum/domainValue_datum.
> While correct and sensible if we continue the abuse, these patches feel
> like putting lipstick on a pig.
Agreed. I spent some time trying to do it better, with results
shown at [1]. If we
On 03/09/2024 18:18, Xing Guo wrote:
On Tue, Sep 3, 2024 at 8:09 PM Andreas Karlsson wrote:
On 8/31/24 10:04 AM, Xing Guo wrote:
The nullness of casetest.value can be determined at the JIT compile
time. We can emit fewer codes by utilizing this property. The attached
patch is trying to fix it
On Tue, Sep 3, 2024 at 8:09 PM Andreas Karlsson wrote:
>
> On 8/31/24 10:04 AM, Xing Guo wrote:
> > The nullness of casetest.value can be determined at the JIT compile
> > time. We can emit fewer codes by utilizing this property. The attached
> > patch is trying to fix it.
>
> I have not reviewed
On 8/31/24 10:04 AM, Xing Guo wrote:
The nullness of casetest.value can be determined at the JIT compile
time. We can emit fewer codes by utilizing this property. The attached
patch is trying to fix it.
I have not reviewed the code yet but the idea seems good.
But I wonder if we shouldn't inst
