Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Georgy Artos <georgyartos(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
Date: 2025-02-04 14:53:41
Message-ID: 5CDFBA04-DEBC-4BFD-BDC0-42CA1828AAD0@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 4 Feb 2025, at 15:43, Georgy Artos <georgyartos(at)gmail(dot)com> wrote:

> Post Scriptum: There's a non-namespaced/schematized query at [4],
> however I guess it's really just me not understanding the pg_dump
> code...

> [4] https://github.com/postgres/postgres/blob/53a49365052026907afff7613929710d1e7f0da0/src/bin/pg_dump/pg_dump.c#L1723C18-L1723C32

Thanks for the report, any such query should be fixed. In this case it seems
fine, partition_tree is set up as a recursive common table expression a few
lines earlier in the function:

if (with_child_tables)
{
appendPQExpBuffer(query, "WITH RECURSIVE partition_tree (relid) AS (\n");
}

--
Daniel Gustafsson

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Laurenz Albe 2025-02-04 15:13:46 Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query
Previous Message Georgy Artos 2025-02-04 14:43:22 Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications