Re: Add --extra-dependencies and immediate data dumping for pg_dump/pg_upgrade

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add --extra-dependencies and immediate data dumping for pg_dump/pg_upgrade
Date: 2026-03-13 13:23:50
Message-ID: 5835b04f-c53a-4f45-84a3-ea681f3fb338@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.01.26 14:43, Jeevan Chalke wrote:
> Thanks for the feedback, Matthias; I agree with your assessment.
> Currently, Postgres lacks a native mechanism for tracking dependencies
> between a table and the specific rows of another table. While certain
> extensions like PostGIS introduce these patterns, they remain non-
> standard edge cases.
>
> Implementing a fix in the core backend seems like overkill for this
> scenario. Since the failure is specific to the upgrade path, targeting |
> pg_dump| and |pg_upgrade| is a significantly less invasive approach.
> Notably, this patch triggers an immediate dump of the referenced table
> data -- an unconventional behavior that is better handled in the client
> binaries than in the backend. Consequently, this approach would require
> new options for these binaries to explicitly inject those dependency
> details.

How about this: postgis should define its table spatial_ref_sys as
user_catalog_table, and we change pg_dump to dump the contents of user
catalog tables before other DDL.

There is still some work to do here, but at least this sounds like a
more principled approach.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-03-13 13:25:00 Re: Add missing stats_reset column to pg_stat_database_conflicts view
Previous Message Kirill Reshke 2026-03-13 13:16:34 Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT