Re: [HACKERS] Why have we got both largeobject and large_object test files? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Why have we got both largeobject and large_object test files?
Date
Msg-id 28992.1500314004@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Why have we got both largeobject and large_object test files?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [HACKERS] More flexible LDAP auth search filters?
Next
From: Mark Dilger
Date:
Subject: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends