Re: Logical decoding for operations on zheap tables
От | Andres Freund |
---|---|
Тема | Re: Logical decoding for operations on zheap tables |
Дата | |
Msg-id | 20190103182330.uxwux4eownyrp2et@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Logical decoding for operations on zheap tables (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Logical decoding for operations on zheap tables
|
Список | pgsql-hackers |
Hi, On 2019-01-03 15:13:42 -0300, Alvaro Herrera wrote: > On 2019-Jan-03, Andres Freund wrote: > > > > Apart from this, we need to define different decode functions for > > > zheap operations as the WAL data is different for heap and zheap, so > > > same functions can't be used to decode. > > > > I'm very strongly opposed to that. We shouldn't have expose every > > possible storage method to output plugins, that'll make extensibility > > a farce. I think we'll either have to re-form a HeapTuple or decide > > to bite the bullet and start exposing tuples via slots. > > Hmm, without looking at the patches, I agree that the tuples should be > given as slots to the logical decoding interface. I wonder if we need a > further function in the TTS interface to help decoding, or is the > "getattr" stuff sufficient. What precisely do you mean with "getattr stuff"? I'd assume that you'd normally do a slot_getallattrs() and then access tts_values/nulls directly. I don't think there's anything missing in the slot interface itself, but using slots probably would require some careful considerations around memory management, possibly a decoding specific slot implementation even. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: