Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ )
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Ian Barwick <ian.barwick@2ndquadrant.com>, Sergei Kornilov <sk@zsrv.org>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2019-07-23T08:10:23Z
Lists: pgsql-hackers
On Mon, Jul 22, 2019 at 12:58:40PM -0400, Alvaro Herrera wrote: > Maybe it's just me, but it seems weird to try to forestall a problem > that cannot occur by definition. I would rather remove the escaping, > and add a one-line comment explaining why we don't do it? No objections with doing that either, really. Perhaps you would prefer pushing a patch among those lines by yourself? One argument that I got in mind to justify the escaping would be if we add a new feature in pg_basebackup to write a new set of recovery options on an existing data folder, which does not require an option. In this case, if the escaping does not exist, starting the server would fail with a confusing parsing error if a quote is added to the slot name. But if the escaping is done, then we would get a correct error that the replication slot value includes an incorrect character. If such an hypothetical option is added, most likely this would be noticed anyway, so that's mainly nannyism from my side. -- Michael
Commits
-
Don't uselessly escape a string that doesn't need escaping
- 66abcce55f12 11.5 landed
- 5ac684381df1 12.0 landed
- 52608f341607 10.10 landed
- 0f9133b66b56 9.6.15 landed
- 0994cfc0ac85 13.0 landed
-
pg_basebackup: Add --slot option
- 0dc848b0314d 9.6.0 cited