Re: Logical decoding for operations on zheap tables

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical decoding for operations on zheap tables
Date: 2019-01-03 18:23:30
Message-ID: 20190103182330.uxwux4eownyrp2et@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-01-03 18:38:30 Re: Logical decoding for operations on zheap tables
Previous Message Tom Lane 2019-01-03 18:22:24 Re: BUG #15548: Unaccent does not remove combining diacritical characters