> On Nov 25, 2023, at 9:47 AM, Alexander Korotkov <aekorot...@gmail.com> wrote:
>
>> Should the patch at least document which parts of the EState are expected to
>> be in which states, and which parts should be viewed as undefined? If the
>> implementors of table AMs rely on any/all aspects of EState, doesn't that
>> prevent future changes to how that structure is used?
>
> New tuple tuple_insert_with_arbiter() table AM API method needs EState
> argument to call executor functions: ExecCheckIndexConstraints(),
> ExecUpdateLockMode(), and ExecInsertIndexTuples(). I think we
> probably need to invent some opaque way to call this executor function
> without revealing EState to table AM. Do you think this could work?
We're clearly not accessing all of the EState, just some specific fields, such
as es_per_tuple_exprcontext. I think you could at least refactor to pass the
minimum amount of state information through the table AM API.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
