On Tue, Aug 1, 2017 at 1:56 PM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > > On Sun, Jul 23, 2017 at 4:10 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> > >> >> > 1. Design an API that returns values/nulls array and convert that into a >> > HeapTuple whenever it is required in the upper layers. All the existing >> > heap form/deform tuples are used for every tuple with some adjustments. >> > >> >> So, this would have the additional cost of form/deform. Also, how >> would it have lesser changes as compare to what you have described >> earlier? > > > Yes, It have the additional cost of form/deform. It is the same approach > that > is described earlier. But I have an intention of modifying everywhere the > HeapTuple is accessed. But with the other prototype changes of removing > HeapTuple usage from triggers, I realized that it needs some clear design > to proceed further, instead of combining those changes with pluggable > Storage API. > > - heap_getnext function is kept as it as and it is used only for system > table > access. > - heap_getnext_slot function is introduced to return the slot whenever the > data is found, otherwise NULL, This function is used in all the places > from > Executor and etc. > > - The TupleTableSlot structure is modified to contain a void* tuple instead > of > HeapTuple. And also it contains the storagehanlder functions. > - heap_insert and etc function can take Slot as an argument and perform the > insert operation. > > The cases where the TupleTableSlot is not possible to sent, form a HeapTuple > from the data and sent it and also note down that it is a HeapTuple data, > not > the tuple from the storage. > .. > > >> >> > 3. Design an API that returns StorageTuple(void *) but the necessary >> > format information of that tuple can be get from the tupledesc. wherever >> > the tuple is present, there exists a tupledesc in most of the cases. How >> > about adding some kind of information in tupledesc to find out the tuple >> > format and call the necessary functions >> > > > > heap_getnext function returns StorageTuple instead of HeapTuple. The tuple > type information is available in the TupleDesc structure. > > All heap_insert and etc function accepts TupleTableSlot as input and perform > the insert operation. This approach is almost same as first approach except > the > storage handler functions are stored in TupleDesc. >
Why do we need to store handler function in TupleDesc? As of now, the above patch series has it available in RelationData and TupleTableSlot, I am not sure if instead of that keeping it in TupleDesc is a good idea. Which all kind of places require TupleDesc to contain handler? If those are few places, can we think of passing it as a parameter? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
