Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch

From: Andres Freund <andres(at)anarazel(dot)de>
To: Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Don't codegen deform code for virtual tuples in expr eval for scan fetch
Date: 2019-09-30 23:07:26
Message-ID: 20190930230726.ulzlrkpehly27enk@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-09-30 09:14:45 -0700, Soumyadeep Chakraborty wrote:
> I don't feel very strongly about the changes I proposed.
>
> > > I completely agree, that was an important consideration.
> > >
> > > I had some purely cosmetic suggestions:
> > > 1. Rename ExecComputeSlotInfo to eliminate the need for the asserts.
> >
> > How does renaming it do so? I feel like the asserts are a good idea
> > independent of anything else?
>
> I felt that encoding the restriction that the function is meant to be called
> only in the context of fetch operations in the function name itself
> ensured that we don't call it from a non-fetch operation - something the
> asserts within ExecComputeSlotInfo() are guarding against.
>
> >
> > > 2. Extract return value to a bool variable for slightly better
> > > readability.
> >
> > To me that seems clearly worse. The variable doesn't add anything, but
> > needing to track more state.>
>
> Agreed.

I pushed this to master. Thanks for your contribution!

Regards,

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hsu, John 2019-10-01 00:10:50 Include RELKIND_TOASTVALUE in get_relkind_objtype
Previous Message Bryn Llewellyn 2019-09-30 22:37:56 PL/pgSQL — "commit" illegal in the executable section of a block statement that has an exception section