Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch
Date
Msg-id 20190930230726.ulzlrkpehly27enk@alap3.anarazel.de
Whole thread Raw
In response to Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
Responses Re: Don't codegen deform code for virtual tuples in expr eval forscan fetch  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Bryn Llewellyn
Date:
Subject: PL/pgSQL — "commit" illegal in the executable section of a block statement that has an exception section
Next
From: "Hsu, John"
Date:
Subject: Include RELKIND_TOASTVALUE in get_relkind_objtype