On Sun, Jul 17, 2022 at 9:04 PM Morris de Oryx <morrisdeoryx@gmail.com> wrote:
> This fails on a partitioned table because xmax() may not exist. In fact, it does exist in all of those tables, but
thesystem doesn't know how to guarantee that. I know which tables are partitioned, and can downgrade the result on
partitionedtables to the count(*) I've been using to date. But now I'm wondering if working with xmax() like this is a
pooridea going forward. I don't want to lean on a feature/behavior that's likely to change. For example, I noticed the
otherday that MERGE does not support RETURNING.
>
> I'd appreciate any insight or advice you can offer.
What is motivating you to want to see the xmax value here? It's not an
unreasonable thing to want to do, IMHO, but it's a little bit niche so
I'm just curious what the motivation is.
I do agree with you that it would be nice if this worked better than
it does, but I don't really know exactly how to make that happen. The
column list for a partitioned table must be fixed at the time it is
created, but we do not know what partitions might be added in the
future, and thus we don't know whether they will have an xmax column.
I guess we could have tried to work things out so that a 0 value would
be passed up from children that lack an xmax column, and that would
allow the parent to have such a column, but I don't feel too bad that
we didn't do that ... should I?
--
Robert Haas
EDB: http://www.enterprisedb.com
