From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: v12 and pg_restore -f- |
Date: | 2019-10-06 20:43:13 |
Message-ID: | 28770.1570394593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
[ redirecting to -hackers ]
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> I saw this and updated our scripts with pg_restore -f-
> https://www.postgresql.org/docs/12/release-12.html
> |In pg_restore, require specification of -f - to send the dump contents to standard output (Euler Taveira)
> |Previously, this happened by default if no destination was specified, but that was deemed to be unfriendly.
> What I didn't realize at first is that -f- has no special meaning in v11 - it
> just writes a file called ./-
Ugh. I didn't realize that either, or I would have made a stink about
this patch. Reducing the risk of getting a dump spewed at you is
completely not worth the cost of making it impossible to have
cross-version-compatible scripting of pg_restore.
Perhaps we could change the back branches so that they interpret "-f -"
as "write to stdout", but without enforcing that you use that syntax.
Nobody is going to wish that to mean "write to a file named '-'", so
I don't think this would be an unacceptable change.
Alternatively, we could revert the v12 behavior change. On the whole
that might be the wiser course. I do not think the costs and benefits
of this change were all that carefully thought through.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-10-06 21:02:49 | Re: v12 and pg_restore -f- |
Previous Message | Justin Pryzby | 2019-10-06 19:08:39 | v12 and pg_restore -f- |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-10-06 21:02:49 | Re: v12 and pg_restore -f- |
Previous Message | Tomas Vondra | 2019-10-06 19:23:13 | Re: How to retain lesser paths at add_path()? |