From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assert pg_class.relnatts is consistent |
Date: | 2020-02-14 15:29:26 |
Message-ID: | 20200214152926.GA7006@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
# oids are a special case; ignore
next if $attname eq 'oid';
# pg_class.relnatts is computed from pg_attribute rows; ignore
next if $catname eq 'pg_class' and $attname eq 'relnatts';
# Raise error unless a value exists.
die "strip_default_values: $catname.$attname undefined\n"
if !defined $row->{$attname};
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-02-14 15:33:04 | Re: allow frontend use of the backend's core hashing functions |
Previous Message | Robert Haas | 2020-02-14 15:28:29 | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |