Re: Why have we got both largeobject and large_object test files?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why have we got both largeobject and large_object test files?
Date: 2017-07-17 17:53:24
Message-ID: 28992.1500314004@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> I happened to notice that the regression tests contain both
>> largeobject.sql and large_object.sql. This seems at best confusing and at
>> worst a source of mistakes. The second file was added in March by commit
>> ff992c074, has never been touched by any other commit, and is only 8 lines
>> long. Was there a really good reason not to incorporate that test into
>> largeobject.sql?

> Just to be clear that we're talking about the same thing- there is no
> 'largeobject.sql' in a clean source tree. There is a 'largeobject.source'
> in src/test/regress/input which is converted to largeobject.sql.

Right, sorry for the imprecision.

> As for the general question of if the two could be merged, I can't think
> of any reason off-hand why that wouldn't work, nor do I have any
> particular recollection as to why I created a new file instead of using
> the existing. My shell history tells me that I found largeobject.source
> while crafting the test case but not why I didn't use it.

You've got shell history back to March? Wow.

> The main thing is that the large_object.sql was specifically added to
> test pg_upgrade/pg_dump, so the created object needs to be kept around
> in the regression database with the comment after the tests run for that
> to happen.

Right. I was thinking of just appending large_object.sql to the end of
the other file.

It's possible that there's some issue involving race conditions against
some concurrent test, but I'll look around.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2017-07-17 19:54:31 Re: Something for the TODO list: deprecating abstime and friends
Previous Message Magnus Hagander 2017-07-17 17:08:04 Re: More flexible LDAP auth search filters?