Re: [PATCHES] large object regression tests

On Sun, 24 Sep 2006, Jeremy Drake wrote:

> On Thu, 21 Sep 2006, Tom Lane wrote:
>
> > I suggest that instead of testing the server-side lo_import/lo_export
> > functions, perhaps you could test the psql equivalents and write and
> > read a file in psql's working directory.
<snip>
> In the mean time, I will alter the test to also test the psql backslash
> commands based on how the copy equivalents are tested, since I had
> forgotten them and they need to be tested also.

I just tried using the \lo_import command in a regression test, and I
think I figured out why this will not work:

$ make check
...
largeobject ... FAILED
...

$ cat regression.diffs
*** ./expected/largeobject.out Sun Sep 24 19:55:25 2006
--- ./results/largeobject.out Sun Sep 24 19:55:58 2006
***************
*** 188,194 ****
(1 row)

\lo_import 'results/lotest.txt'
! lo_import 31138
\set newloid :LASTOID
-- This is a hack to test that export/import are reversible
-- This uses knowledge about the inner workings of large object
mechanism
--- 188,194 ----
(1 row)

\lo_import 'results/lotest.txt'
! lo_import 31199
\set newloid :LASTOID
-- This is a hack to test that export/import are reversible
-- This uses knowledge about the inner workings of large object
mechanism

======================================================================

Yes, that's the large object OID in the output there, and it is different
each run (as I expect). If you look at src/bin/psql/large_obj.c line 192,
you see:

fprintf(pset.queryFout, "lo_import %u\n", loid);

Which is executed unconditionally whenever the lo_import is successful.
While in a normal circumstance, it is quite necessary to know the loid,
since it does change each call, in this case it serves to break the diffs,
and so I guess it is impossible to use the \lo_import command in a
regression test.

--
The first time, it's a KLUDGE!
The second, a trick.
Later, it's a well-established technique!
-- Mike Broido, Intermetrics