<div>Hi!</div><div> </div><div>What's the state with this issue?</div><div> </div><div>-- <br />С уважением, Павел</div><div> </div><div> </div><div> </div><div>13.08.2020, 07:13, "Amit Langote" <amitlangote09(at)gmail(dot)com>:</div><blockquote><p>Hi,<br /><br />On Thu, Aug 13, 2020 at 1:27 AM Andres Freund <<a href="mailto:andres(at)anarazel(dot)de" rel="noopener noreferrer">andres(at)anarazel(dot)de</a>> wrote:</p><blockquote> On 2020-08-12 14:19:12 +0900, Amit Langote wrote:<br /> > On Wed, Aug 12, 2020 at 1:08 PM Tom Lane <<a href="mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us" rel="noopener noreferrer">tgl(at)sss(dot)pgh(dot)pa(dot)us</a>> wrote:<br /> > > It's not like we don't have a technology for doing that. The way this<br /> > > ideally would work, IMV, is that the parent partitioned table either<br /> > > has or doesn't have a given system column. If it does, then every<br /> > > child must too, just like the way things work for user columns.<br /> ><br /> > Ah, I may have misread "insisting that all partitions have a given<br /> > system column" as doing that on every query, but maybe Andres meant<br /> > what you are describing here.<br /><br /> I think Tom's formulation makes sense.</blockquote><p><br />Yes, I agree.<br /> </p><blockquote> > > This'd require (a) some sort of consensus about which kinds of system<br /> > > columns can make sense --- as Andres noted, 32-bit xmin might not be<br /> > > the best choice here --- and (b) some notation for users to declare<br /> > > which of these columns they want in a partitioned table. Once upon<br /> > > a time we had WITH OIDS, maybe that idea could be extended.<br /> ><br /> > For (a), isn't there already a consensus that all table AMs support at<br /> > least the set of system columns described in 5.5 System Columns [1]<br /> > even if the individual members of that set are no longer the best<br /> > choice at this point?<br /><br /> I don't think there is. I don't think xmin/xmax/cmin/cmax should be<br /> among those. tableoid and ctid are handled by generic code, so I think<br /> they would be among the required columns.<br /><br /> Where do you see that concensus?</blockquote><p><br />Perhaps I was wrong to use the word consensus. I was trying to say<br />that table AM extensibility work didn't change the description in 5.5<br />System Columns, which still says *all* tables, irrespective of their<br />AM, implicitly have those columns, so I assumed we continue to ask AM<br />authors to have space for those columns in their tuples. Maybe, that<br />list is a legacy of heapam and updating it in am AM-agnostic manner<br />would require consensus.<br /> </p><blockquote> > I do agree that we'd need (b) in some form to require AMs to fill<br /> > those columns which it seems is not the case currently.<br /><br /> Hm? What are you referencing here?</blockquote><p><br />I meant that WITH <a-system-column> specified on a table presumably<br />forces an AM to ensure that the column is present in its tuples, like<br />WITH OIDS specification on a table would force heapam to initialize<br />the oid system column in all tuples being inserted into that table.<br />Lack of the same notation for other system columns means that AMs<br />don't feel forced to ensure those columns are present in their tuples.<br />Also, having the WITH notation makes it easy to enforce that all<br />partitions in a given hierarchy have AMs that respect the WITH<br />specification.<br /> </p>--<br />Amit Langote<br />EnterpriseDB: <a href="http://www.enterprisedb.com/" rel="noopener noreferrer">http://www.enterprisedb.com</a></blockquote>