pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgsql: In pg_dump, don't dump a stats object unless dumping underlying
6+ messages / 1 participants
[nested] [flat]

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/7418767f11d11ca4003ed3e8e96296eabb2acfe1

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 30 +++++++++++++++++++++++++++---
src/bin/pg_dump/pg_dump.h        |  3 ++-
src/bin/pg_dump/t/002_pg_dump.pl |  5 +++--
3 files changed, 32 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/b2c9936a7156926ace70b89ffb9cfbe1e3b9a559

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 30 +++++++++++++++++++++++++++---
src/bin/pg_dump/pg_dump.h        |  3 ++-
src/bin/pg_dump/t/002_pg_dump.pl |  5 +++--
3 files changed, 32 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/1e0841426e968f184277e7638227b16fb3cdca7a

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 30 +++++++++++++++++++++++++++---
src/bin/pg_dump/pg_dump.h        |  3 ++-
src/bin/pg_dump/t/002_pg_dump.pl |  6 +++---
3 files changed, 32 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/aa2e323eedc9e3cbad4eae19b309f92c8ba8afeb

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 30 +++++++++++++++++++++++++++---
src/bin/pg_dump/pg_dump.h        |  1 +
src/bin/pg_dump/t/002_pg_dump.pl |  6 +++---
3 files changed, 31 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/8d4e8b746815505c3b808ab96674ec2e140afc56

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 30 +++++++++++++++++++++++++++---
src/bin/pg_dump/pg_dump.h        |  1 +
src/bin/pg_dump/t/002_pg_dump.pl |  6 +++---
3 files changed, 31 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgsql: In pg_dump, don't dump a stats object unless dumping underlying
@ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

In pg_dump, don't dump a stats object unless dumping underlying table.

If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.

(When and if we get cross-table stats objects, it might be profitable
to think a little harder about what to do with them.  But for now
there seems no point in considering a stats object as anything but
an appendage of its table.)

Rian McGuire and Tom Lane, per report from Rian McGuire.
Back-patch to supported branches.

Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/69d7edb06fc69da114b075be58dd4318916500e5

Modified Files
--------------
src/bin/pg_dump/pg_dump.c        | 28 ++++++++++++++++++++++++++--
src/bin/pg_dump/pg_dump.h        |  1 +
src/bin/pg_dump/t/002_pg_dump.pl |  6 +++---
3 files changed, 30 insertions(+), 5 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2023-12-29 15:57 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox