On 12/16/2014 04:34 AM, Amit Kapila wrote:
> On Tue, Dec 16, 2014 at 12:58 PM, Amit Kapila <amit.kapila16@gmail.com
> <mailto:amit.kapila16@gmail.com>> wrote:
> >
> > On Sun, Dec 14, 2014 at 11:54 AM, Amit Kapila
> <amit.kapila16@gmail.com <mailto:amit.kapila16@gmail.com>> wrote:
> > > On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
> > > > 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.
> > >
> >
> > I have chosen #3 (Make pg_basebackup check for and fail on symlinks
> > containing characters (currently newline only) it can't handle) from the
> > different options suggested by Tom. This keeps the format same as
> > previous and human readable.
> >
>
> Actually, here instead of an error a warning is issued and that particular
> path (containing new line) will be skipped. This is similar to what
> is already done for the cases when there is any problem in reading
> link paths.
>
I'm not clear why human readability is the major criterion here. As for
that, it will be quite difficult for a human to distinguish a name with
a space at the end from one without. I really think a simple encoding
scheme would be much the best. For normal cases it will preserve
readability completely, and for special cases it will preserve lack of
any ambiguity.
cheers
andrew
