Re: assert pg_class.relnatts is consistent
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: John Naylor <john.naylor@2ndquadrant.com>,
Amit Langote <amitlangote09@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-02-14T19:00:56Z
Lists: pgsql-hackers
Attachments
- v3-0001-no-manual-relnatts-assignment.patch (text/x-diff) patch v3-0001
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2020-Feb-14, John Naylor wrote: >> One possible objection to what I wrote above is that it adds a >> different kind of special case, but in a sneaky way. Perhaps it would >> be more principled to treat it the same as oid after all. If we do >> that, it would help to add a comment that we can't treat relnatts like >> pronangs, since we need more information than what's in each pg_class >> row. > How about something like this? (untested) I think John's idea of setting a dummy BKI_DEFAULT value is better, as that means the only code that has to worry about this directly is the code that's actually filling in relnatts. As far as said code goes, we don't need an additional global variable when we can just look in the $catalogs data structure; and I'm not a fan of cramming this into the OID-assignment logic just to save a loop. So that leads me to the attached. (I agree with Alvaro's thought of shortening AddDefaultValues, but didn't do that here.) regards, tom lane
Commits
-
Update obsolete comment.
- faade5d4c6d8 13.0 landed
-
Clarify coding in Catalog::AddDefaultValues.
- 9d1ec5a8e155 13.0 landed
-
Run "make reformat-dat-files".
- b78542b9e975 13.0 landed
-
Don't require pg_class.dat to contain correct relnatts values.
- 86ff085e8388 13.0 landed