Andreas Karlsson writes:
> On 2/15/20 1:57 AM, Tom Lane wrote:
>> Hm. So, these oversights are certainly bugs in narrow terms. However,
>> they've all been like that for a *long* time --- the three instances
>> you found date to 2005, 2006, and 2008 according to "git blame".
>> The complete lack
On 2/15/20 1:57 AM, Tom Lane wrote:
Hm. So, these oversights are certainly bugs in narrow terms. However,
they've all been like that for a *long* time --- the three instances
you found date to 2005, 2006, and 2008 according to "git blame".
The complete lack of complaints shows that nobody cares
Ashwin Agrawal writes:
> On Fri, Feb 14, 2020 at 4:57 PM Tom Lane wrote:
>> Hm. So, these oversights are certainly bugs in narrow terms. However,
>> they've all been like that for a *long* time --- the three instances
>> you found date to 2005, 2006, and 2008 according to "git blame".
>> The co
On Fri, Feb 14, 2020 at 4:57 PM Tom Lane wrote:
> Ashwin Agrawal writes:
> > In general, the variable LN_S is 'ln -s', however, LN_S changes to 'cp
> > -pR' if configure finds the file system does not support symbolic
> > links.
> > I was playing with 'ln' for some other reason where I symbolic
Ashwin Agrawal writes:
> In general, the variable LN_S is 'ln -s', however, LN_S changes to 'cp
> -pR' if configure finds the file system does not support symbolic
> links.
> I was playing with 'ln' for some other reason where I symbolic linked
> it to '/bin/false'. That revealed the failure for
>
re for
src/backend/Makefile. Greping for 'ln -s' revealed three places it's
used. Attaching the patch to fix the same.
From 60b3374de1e4d0fd143c2a7b3bf78893e32579af Mon Sep 17 00:00:00 2001
From: Ashwin Agrawal
Date: Fri, 14 Feb 2020 16:16:37 -0800
Subject: [PATCH v1] Use LN_S in
