Re: problem with RETURNING and update row movement

On Thu, Sep 24, 2020 at 2:47 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Sep 24, 2020 at 4:25 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> BTW, the discussion so far on the other thread is oblivious to the
> issue being discussed here, where we need to find a way to transfer
> system attributes between a pair of partitions that are possibly
> incompatible with each other in terms of what set of system attributes
> they support.

Yeah, we should discuss the two issues together.

> Although, if we prevent accessing system attributes
> when performing the operation on partitioned tables, like what you
> seem to propose below, then we wouldn't really have that problem.

Yeah, I think so.

> > Yeah, but for the other issue, I started thinking that we should just
> > forbid referencing xmin/xmax/cmin/cmax in 12, 13, and HEAD...
>
> When the command is being performed on a partitioned table you mean?

Yes. One concern about that is triggers: IIUC, triggers on a
partition as-is can or can not reference xmin/xmax/cmin/cmax depending
on whether a dedicated tuple slot for the partition is used or not.
We should do something about this if we go in that direction?

> That is, it'd be okay to reference them when the command is being
> performed directly on a leaf partition, although it's another thing
> whether the leaf partitions themselves have sensible values to provide
> for them.

I think so too.

Best regards,
Etsuro Fujita