BUG #18245: pg_restore accepts same output file name as input file name
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:t72264psql -h localhost -U postgresBuilt from patchset v2 (message #2), September 20, 2026 at 09:47 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 t72264_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 t72264_2 && git checkout t72264_2Patchset v2 (message #2) is on t72264_2
The following bug has been logged on the website:
Bug reference: 18245
Logged by: Mohammad Al Zouabi
Email address: mb.alzouabi@gmail.com
PostgreSQL version: 14.10
Operating system: macOS
Description:
Please let it fail when the user passes the same name for the output as the
input.
I just lost a very important .tar file because I forgot to replace .tar with
.sql.
Thanks!
On 13 Dec 2023, at 04:39, PG Bug reporting form <noreply@postgresql.org> wrote:
Please let it fail when the user passes the same name for the output as the
input.
I think this sounds like a fair restriction, input and output being the same
seems much more likely to be a copy/paste issue than an interesting usecase.
Something like the attached (untested) sketch should be enough I think.
--
Daniel Gustafsson
Hi,
On Wed, Dec 13, 2023 at 09:44:26AM +0100, Daniel Gustafsson wrote:
On 13 Dec 2023, at 04:39, PG Bug reporting form <noreply@postgresql.org> wrote:
Please let it fail when the user passes the same name for the output as the
input.I think this sounds like a fair restriction, input and output being the same
seems much more likely to be a copy/paste issue than an interesting usecase.
+1
Something like the attached (untested) sketch should be enough I think.
I'm wondering if it would be worth adding some canonicalize_path() calls while
at it, ISTM that such mistakes are likely to happen when invoking pg_restore
manually, so having slightly different wording for the exact same file wouldn't
surprising.
Julien Rouhaud <rjuju123@gmail.com> writes:
On Wed, Dec 13, 2023 at 09:44:26AM +0100, Daniel Gustafsson wrote:
Something like the attached (untested) sketch should be enough I think.
I'm wondering if it would be worth adding some canonicalize_path() calls while
at it, ISTM that such mistakes are likely to happen when invoking pg_restore
manually, so having slightly different wording for the exact same file wouldn't
surprising.
I'm a little dubious about the value of this; but if we're going to do
it, comparing post-canonicalize_path strings does seem like the right
way.
regards, tom lane