Amit Kapila <amit.kapil...@gmail.com> writes: >> On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <t...@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 nice from the viewpoint of Windows users. * Make pg_basebackup check for and fail on symlinks containing characters it can't handle. Pretty icky, though I suppose there's some argument that things like newlines wouldn't be in any rational tablespace path. But I doubt you can make that argument for spaces, quotes, or backslashes. 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