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
knowledgeabout 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
knowledgeabout 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