Re: pgsql-server/src backend/bootstrap/Tag: backen ... - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql-server/src backend/bootstrap/Tag: backen ...
Date
Msg-id 427.1063175097@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql-server/src backend/bootstrap/Tag: backen ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pgsql-server/src backend/bootstrap/Tag: backen ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pgsql-server/src backend/bootstrap/Tag: backen ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-committers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't understand why people are wasting time worrying about a few
> files resurected in CVS to assist Win32.

Because this approach incurs a long-term cost (CVS storage) to buy a
short-term benefit (Windows developers might not need flex&bison).
The long-term cost is not trivial --- if you look at the CVS history
for the short interval that we kept these files in CVS, you will see
lots of five-thousand-line diffs corresponding to trivial changes in
the gram.y source.  We abandoned that approach for very good reasons.

It was already pointed out that Windows users wouldn't get any benefit
at all unless they installed a CVS client.  Surely if they can do that,
they can install flex&bison too.

We decided years ago that the minimum requirement to use our CVS sources
on Unix systems was the ability to run flex and bison locally (and we've
not had much patience with people running old versions of same, either).
I don't see the argument why people helping to develop a cutting-edge
Windows port should be expected to be less competent than every single
Unix CVS user.  (Other than the fact that they're using Windows in the
first place of course ;-)))

            regards, tom lane

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql-server/src/backend commands/typecmds.c e ...
Next
From: Christof Petig
Date:
Subject: Re: pgsql-server/src backend/bootstrap/Tag: backen ...