On Wed, Aug 23, 2017 at 11:05 AM, Haribabu Kommi
> On Mon, Aug 21, 2017 at 7:25 PM, Amit Kapila <amit.kapil...@gmail.com>
>> On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi
>> <kommi.harib...@gmail.com> wrote:
>> > On Sun, Aug 13, 2017 at 5:17 PM, Amit Kapila <amit.kapil...@gmail.com>
>> > wrote:
>> >> Also, it is quite possible that some of the storage Am's don't even
>> >> want to return bool as a parameter from HeapTupleSatisfies* API's. I
>> >> guess what we need here is to provide a way so that different storage
>> >> am's can register their function pointer for an equivalent to
>> >> satisfies function. So, we need to change
>> >> SnapshotData.SnapshotSatisfiesFunc in some way so that different
>> >> handlers can register their function instead of using that directly.
>> >> I think that should address the problem you are planning to solve by
>> >> omitting buffer parameter.
>> > Thanks for your suggestion. Yes, it is better to go in the direction of
>> > SnapshotSatisfiesFunc.
>> > I verified the above idea of implementing the Tuple visibility functions
>> > and assign them into the snapshotData structure based on the snapshot.
>> > The Tuple visibility functions that are specific to the relation are
>> > available
>> > with the RelationData structure and this structure may not be available,
>> Which functions are you referring here? I don't see anything in
>> tqual.h that uses RelationData.
> With storage API's, the tuple visibility functions are available with
> and those are needs used to update the SnapshotData structure
> SnapshotSatisfiesFunc member.
> But the RelationData is not available everywhere, where the snapshot is
> but it is available every place where the tuple visibility is checked. So I
> just changed
> the way of checking the tuple visibility with the information of snapshot by
> the corresponding tuple visibility function from RelationData.
> If SnapshotData provides MVCC, then the MVCC specific tuple visibility
> function from
> RelationData is called. The SnapshotSatisfiesFunc member is changed to a
> that holds the tuple visibility type such as MVCC, DIRTY, SELF and etc.
> the visibility check is needed, the corresponding function is called.
It will be easy to understand and see if there is some better
alternative once you have something in the form of a patch.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: