On Mon, Sep 27, 2010 at 4:12 PM, David Fetter <david@fetter.org> wrote:
> On Mon, Sep 27, 2010 at 03:11:07PM -0400, Robert Haas wrote:
>> On Mon, Sep 27, 2010 at 2:09 PM, David Fetter <david@fetter.org> wrote:
>> > On Mon, Sep 27, 2010 at 01:53:45PM -0400, Robert Haas wrote:
>> >> On Mon, Sep 27, 2010 at 1:34 PM, Alvaro Herrera
>> >> <alvherre@commandprompt.com> wrote:
>> >> > Excerpts from David E. Wheeler's message of lun sep 27 12:25:31 -0400 2010:
>> >> >> On Sep 27, 2010, at 5:05 AM, Peter Eisentraut wrote:
>> >> >>
>> >> >> > Um, no.
>> >> >> >
>> >> >> > In the meantime, I have arrived at the conclusion that doing this isn't
>> >> >> > worth it because it will break all regression test output. We can fix
>> >> >> > the stuff in our tree, but pg_regress is also used externally, and those
>> >> >> > guys would have a nightmare with this change. Perhaps if there is
>> >> >> > another more significant revision of the table style in the future, we
>> >> >> > should keep this issue in mind.
>> >> >>
>> >> >> Or change the way pg_regress works.
>> >> >
>> >> > Perhaps using unaligned mode? The problem with that is that it becomes
>> >> > very difficult to review changes to expected output.
>> >>
>> >> Uh, yuck! If we don't care about changing the expected output, we can
>> >> just trim the whitespace as Peter suggested originally.
>> >
>> > I must be missing something pretty crucial here as far as the
>> > complexity of changing all the regression tests. Wouldn't trimming
>> > all trailing whitespace do the trick?
>>
>> Sure. But everyone using pg_regress will have to update their
>> regression test expected outputs.
>
> Again, I must be missing something super important. What is it that
> prevents people from doing
>
> find . -type f |xargs perl -pi.bak -e 's/\s+$//g'
>
> or moral equivalent on their pg_regression tree?
I assume it's not that simple, but I haven't tried it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company