Amit Kapila <amit.kapila16@gmail.com> writes:
>> On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 1. The patch is completely naive about what might be in the symlink
>>> path string; eg embedded spaces in the path would break it. On at
>>> least some platforms, newlines could be in the path as well. I'm not
>>> sure about how to guard against this while maintaining human readability
>>> of the file.
> One way to deal with this could be to append a delimiter(which is not
> allowed
> in tablespace path like quote (\')) at the end of tablespace path while
> writing the same to symlink label file and then use that as end marker while
> reading it from file.
What makes you think quote isn't allowed in tablespace paths? Even if we
were to disallow it at the SQL level, there'd be nothing stopping a DBA
from changing the path after the fact by redefining the symlink outside
SQL --- something I believe we specifically meant to allow, considering
we went to the trouble of getting rid of the pg_tablespace.spclocation
column.
Pretty much the only character we can be entirely certain is not in a
symlink's value is \0. As Alvaro mentioned, using that in the file
is a possible alternative, although it could easily confuse some users
and/or text editors. The only other alternatives I can see are:
* Go over to a byte-count-then-value format. Also possible, also rather unfriendly from a user's standpoint.
* Establish an escaping convention, eg backslash before any funny characters. Unfortunately backslash wouldn't be too
nicefrom the viewpoint of Windows users.
* Make pg_basebackup check for and fail on symlinks containing characters it can't handle. Pretty icky, though I
supposethere's some argument that things like newlines wouldn't be in any rational tablespace path. But I doubt you can
makethat argument for spaces, quotes, or backslashes.
regards, tom lane
