Tom Lane wrote:
> Given our inability to come to a consensus on rejiggering the uses of
> "missing", I think maybe we should just apply the original patch and
> call it good.
For the record: Tom applied this patch as commit dccf8e9e608824ce15.
--
Álvaro Herrerahttp://www.2ndQuad
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> On 11/11/15 12:34 PM, Tom Lane wrote:
>>> I was thinking more of removing the "missing" script and associated logic
>>> entirely, rather than making PGXS a special case.
>> Well, about a year ago people were arguing for the opposite change in
>>
Andrew Dunstan writes:
> On 11/11/2015 12:34 PM, Tom Lane wrote:
>> I was thinking more of removing the "missing" script and associated logic
>> entirely, rather than making PGXS a special case. I think we should do
>> our best to minimize differences between behaviors in core builds and
>> PGXS
On 11/11/2015 12:34 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 11/2/15 4:07 PM, Tom Lane wrote:
I wonder how much we need that script at all though. If, say, configure
doesn't find bison, what's so wrong with just defining BISON=bison and
letting the usual shell "bison: command not fou
Peter Eisentraut wrote:
> On 11/11/15 12:34 PM, Tom Lane wrote:
> > I was thinking more of removing the "missing" script and associated logic
> > entirely, rather than making PGXS a special case. I think we should do
> > our best to minimize differences between behaviors in core builds and
> > PGX
On 11/11/15 12:34 PM, Tom Lane wrote:
> I was thinking more of removing the "missing" script and associated logic
> entirely, rather than making PGXS a special case. I think we should do
> our best to minimize differences between behaviors in core builds and
> PGXS builds, if only because we don't
Peter Eisentraut writes:
> On 11/2/15 4:07 PM, Tom Lane wrote:
>> I wonder how much we need that script at all though. If, say, configure
>> doesn't find bison, what's so wrong with just defining BISON=bison and
>> letting the usual shell "bison: command not found" error leak through?
> I agree.
On 11/2/15 4:07 PM, Tom Lane wrote:
> I wonder how much we need that script at all though. If, say, configure
> doesn't find bison, what's so wrong with just defining BISON=bison and
> letting the usual shell "bison: command not found" error leak through?
I agree. Something like the attached pat
On Nov 2, 2015, at 1:07 PM, Tom Lane wrote:
> I wonder how much we need that script at all though. If, say, configure
> doesn't find bison, what's so wrong with just defining BISON=bison and
> letting the usual shell "bison: command not found" error leak through?
+1 This would certainly make it
Robert Haas writes:
> On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote:
>> Currently, config/missing isn't being installed. This can lead to confusing
>> error messages, such as if Perl isn't found and something needs it [1].
>> Attached patch adds it to install and uninstall recipes.
> I find i
Robert Haas wrote:
> On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote:
> > Currently, config/missing isn't being installed. This can lead to confusing
> > error messages, such as if Perl isn't found and something needs it [1].
> > Attached patch adds it to install and uninstall recipes.
>
> I fin
On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby wrote:
> Currently, config/missing isn't being installed. This can lead to confusing
> error messages, such as if Perl isn't found and something needs it [1].
> Attached patch adds it to install and uninstall recipes.
I find it somewhat hard to believe t
Currently, config/missing isn't being installed. This can lead to
confusing error messages, such as if Perl isn't found and something
needs it [1]. Attached patch adds it to install and uninstall recipes.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data
13 matches
Mail list logo