Re: pg_basebackup vs. Windows and tablespaces

On 12/16/2014 04:34 AM, Amit Kapila wrote:
> On Tue, Dec 16, 2014 at 12:58 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com
> <mailto:amit(dot)kapila16(at)gmail(dot)com>> wrote:
> >
> > On Sun, Dec 14, 2014 at 11:54 AM, Amit Kapila
> <amit(dot)kapila16(at)gmail(dot)com <mailto:amit(dot)kapila16(at)gmail(dot)com>> wrote:
> > > On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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