Addition of pg_dump --no-publications
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36671psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 28, 2026 at 06:50 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36671_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36671_2 && git checkout t36671_2Patchset v2 (message #2) is on t36671_2
Hi all,
I imagine that pg_dump -s would be the basic operation that users
would do first before creating a subcription on a secondary node, but
what I find surprising is that publications are dumped by default. I
don't find confusing that those are actually included by default to be
consistent with the way subcriptions are handled, what I find
confusing is that there are no options to not dump them, and no
options to bypass their restore.
So, any opinions about having pg_dump/pg_restore --no-publications?
Thanks,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 11, 2017 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
I imagine that pg_dump -s would be the basic operation that users
would do first before creating a subcription on a secondary node, but
what I find surprising is that publications are dumped by default. I
don't find confusing that those are actually included by default to be
consistent with the way subcriptions are handled, what I find
confusing is that there are no options to not dump them, and no
options to bypass their restore.So, any opinions about having pg_dump/pg_restore --no-publications?
And that's really a boring patch, giving the attached.
--
Michael
On 5/11/17 21:59, Michael Paquier wrote:
On Thu, May 11, 2017 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:I imagine that pg_dump -s would be the basic operation that users
would do first before creating a subcription on a secondary node, but
what I find surprising is that publications are dumped by default. I
don't find confusing that those are actually included by default to be
consistent with the way subcriptions are handled, what I find
confusing is that there are no options to not dump them, and no
options to bypass their restore.So, any opinions about having pg_dump/pg_restore --no-publications?
And that's really a boring patch, giving the attached.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 12, 2017 at 10:59:27AM +0900, Michael Paquier wrote:
On Thu, May 11, 2017 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:I imagine that pg_dump -s would be the basic operation that users
would do first before creating a subcription on a secondary node, but
what I find surprising is that publications are dumped by default. I
don't find confusing that those are actually included by default to be
consistent with the way subcriptions are handled, what I find
confusing is that there are no options to not dump them, and no
options to bypass their restore.So, any opinions about having pg_dump/pg_restore --no-publications?
And that's really a boring patch, giving the attached.
While it's consistent with surrounding code, I find the use of ints to
express what is in essence a boolean condition puzzling. Any
insights?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter <david@fetter.org> writes:
While it's consistent with surrounding code, I find the use of ints to
express what is in essence a boolean condition puzzling. Any
insights?
IIRC, it's forced by the getopt_long API, particularly the way that
the long-options struct has to be declared.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 12, 2017 at 10:19 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 5/11/17 21:59, Michael Paquier wrote:
On Thu, May 11, 2017 at 3:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:I imagine that pg_dump -s would be the basic operation that users
would do first before creating a subcription on a secondary node, but
what I find surprising is that publications are dumped by default. I
don't find confusing that those are actually included by default to be
consistent with the way subcriptions are handled, what I find
confusing is that there are no options to not dump them, and no
options to bypass their restore.So, any opinions about having pg_dump/pg_restore --no-publications?
And that's really a boring patch, giving the attached.
committed
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers