Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vvi5l-00FFtH-35 for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 20:36:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vvi5k-00FMqs-2Y for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 20:36:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vvi5k-00FMqf-1d for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 20:36:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vvi5h-00000001MNE-0KR8 for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 20:36:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 61QKa7bF732108; Thu, 26 Feb 2026 15:36:07 -0500 From: Tom Lane To: Corey Huinker cc: nathandbossart@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump In-reply-to: References: Comments: In-reply-to Corey Huinker message dated "Wed, 25 Feb 2026 16:22:06 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <732106.1772138167.1@sss.pgh.pa.us> Date: Thu, 26 Feb 2026 15:36:07 -0500 Message-ID: <732107.1772138167@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Corey Huinker writes: > Per side conversation in [1], this patch exposes pg_statistic.starelid in > the pg_stats view (0001) and then changes pg_dump to use the starelid in > the queries on pg_stats rather than the combination of schemaname+relname, I don't object to the idea, but I don't like exposing the name "starelid". That just screams implementation artifact, and it goes against the idea that pg_stats is trying to hide the physical representation of pg_statistic. I wish we could use "tableoid", but that's taken already as a system column. Maybe "tableid" or "tablerelid"? Also, the proposed column ordering seems excessively random: n.nspname AS schemaname, c.relname AS tablename, s.starelid AS starelid, a.attnum AS attnum, a.attname AS attname, stainherit AS inherited, I could see either of these as plausible: n.nspname AS schemaname, c.relname AS tablename, s.starelid AS tableid, a.attname AS attname, a.attnum AS attnum, stainherit AS inherited, n.nspname AS schemaname, c.relname AS tablename, a.attname AS attname, s.starelid AS tableid, a.attnum AS attnum, stainherit AS inherited, but I don't see the rationale behind your version. regards, tom lane