Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] large object regression tests

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, PostgreSQL-development <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] large object regression tests
Date: 2006-09-24 22:19:12
Message-ID: Pine.BSO.4.64.0609241456490.28662@resin.csoft.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Thu, 21 Sep 2006, Tom Lane wrote:

> Jeremy Drake <pgsql-patches(at)jdrake(dot)com> 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.

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-09-24 22:23:32
Subject: Re: pgsql: We're going to have to spell dotless i
Previous:From: Andrew DunstanDate: 2006-09-24 21:55:46
Subject: Re: pgsql: We're going to have to spell dotless i

pgsql-patches by date

Next:From: Claudio NatoliDate: 2006-09-25 00:04:29
Subject: Re: Bad bug in fopen() wrapper code
Previous:From: Magnus HaganderDate: 2006-09-24 20:25:39
Subject: Re: [PATCHES] Include file in regress.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group