On Thu, 21 Sep 2006, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > I put together a patch which adds a regression test for large objects, > > hopefully attached to this message. I would like some critique of it, to > > see if I have gone about it the right way. Also I would be happy to hear > > any additional tests which should be added to it. > > I'd prefer it if we could arrange not to need any absolute paths > embedded into the test, because maintaining tests that require such is > a real PITA --- instead of just committing the actual test output, one > has to reverse-convert it to a ".source" file.
I just copied how the test for COPY worked, since I perceived a similarity in what I needed to do (use external files to load data). > 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. I did not see any precedent for that when I was looking around in the existing tests for an example of how to do things. I am not even sure where the cwd of psql is, so I can put an input file there. Could you provide an example of how this might look, by telling me where to put a file in the src/test/regress tree and the path to give to \lo_import? Besides which, shouldn't both the server-side and psql versions be tested? When I was looking at the copy tests, it looked like the server-side ones were tested, and then the psql ones were tested by exporting and then importing data which was originally loaded from the server-side method. Am I correctly interpreting the precedent, or are you suggesting that the precedent be changed? I was trying to stay as close to the copy tests as possible since the functionality is so similar (transferring data to/from files in the filesystem, either via server-side functions which require absolute paths or via psql \ commands (which I forgot about for the lo funcs)). > I think we could do without the Moby Dick extract too ... I am open to suggestions. I saw one suggestion that I use an image of an elephant, but I suspect that was tongue-in-cheek. I am not very fond of the idea of generating repetitious data, as I think it would be more difficult to determine whether or not the loseek/tell functions put me in the right place in the middle of the file. Perhaps if there was a way to generate deterministic pseudo-random data, that would work (has to be deterministic so the diffs of the output come out right). Anyone have a good example of seeding a random number generator and generating a bunch of bytea which is deterministic cross-platform? > > regards, tom lane > 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. -- Any sufficiently advanced technology is indistinguishable from a rigged demo. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match