On Sun, Dec 14, 2014 at 11:54 AM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
>
> On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
> >
> > Andrew Dunstan <
andrew@dunslane.net> writes:
> > > On 11/20/2014 02:27 AM, Amit Kapila wrote:
> > >> Now the part where I would like to receive feedback before revising the
> > >> patch is on the coding style. It seems to me from Tom's comments that
> > >> he is not happy with the code, now I am not sure which part of the patch
> > >> he thinks needs change. Tom if possible, could you be slightly more
> > >> specific about your concern w.r.t code?
> >
> > > In view of the request above for comments from Tom, I have moved this
> > > back to "Needs Review".
> >
> > Sorry, I was not paying very close attention to this thread and missed
> > the request for comments. A few such:
> >
> > 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.
>
> I will look into this and see what best can be done.
>
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. I think that might defeat the human readable aspect of
this file to an extent, but I am not sure if it is too important to keep it
human readable. I think even if we want to provide some information to
user from internal files, it is always better to provide it via some utility/tool.
Do we support newline in tablespace path?
