Hello all!
 
I just want to point that Npgsql provider for .Net Core builds queries like that (RETURNING xmin) to keep track for concurrency.
This bug stops us from moving to partitioned tables in Postgres 12 with Npgsql.
 
https://www.npgsql.org/efcore/index.html
 
-- 
С уважением, Павел
 
 
 
11.08.2020, 18:34, "Tom Lane" <tgl@sss.pgh.pa.us>:

Robert Haas <robertmhaas@gmail.com> writes:

 On Thu, Jun 4, 2020 at 12:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
 Pavel Biryukov <79166341370@yandex.ru> writes:
 Hello. I'm catch error "virtual tuple table slot does not have system
 attributes" when inserting row into partitioned table with RETURNING
 xmin

 

 I wonder whether it's really correct to classify this as a bug. The
 subsequent discussion essentially boils down to this: the partitioned
 table's children could use any AM, and they might not all use the same
 AM. The system columns that are relevant for the heap may therefore be
 relevant to all, some, or none of the children. In fact, any fixed
 kind of tuple table slot we might choose to use for the parent has
 this problem. If all of the children are of the same type -- and today
 that would have to be heap -- then using that type of tuple table slot
 for the parent as well would make sense. But there's no real reason
 why that's the correct answer in general. If the children are all of
 some other type, using a heap slot for the parent is wrong; and if
 they're all of different types, it's unclear that anything other than
 a virtual slot makes any sense.


Well, if we want to allow such scenarios then we need to forbid queries
from accessing "system columns" of a partitioned table, much as we do for
views. Failing way down inside the executor seems quite unacceptable.

                        regards, tom lane