| 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.
| 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 |