Re: [PATCHES] pg_regress: paths in largeobject test

2007-12-03 Thread Jorgen Austvik - Sun Norway

Tom Lane wrote:

Alvaro Herrera [EMAIL PROTECTED] writes:

I submit that the test is OK as it currently is.


Yeah, I hadn't thought about the different-paths aspect at the time of
making the above comment; but given that, it is correct as-is.


OK, I still think it is easier to debug with the paths there explicitly, 
and I think the test will run just as well with them as without them, 
but it is no biggie.


-J
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Technology Group
adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:[EMAIL PROTECTED]
title:Senior Engineer
tel;work:+47 73 84 21 10 
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
x-mozilla-html:FALSE
url:http://www.sun.com/
version:2.1
end:vcard


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] pg_regress: paths in largeobject test

2007-11-30 Thread Jorgen Austvik - Sun Norway

Tom Lane wrote:

Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes:
I believe the results paths in line 139 and 144 are missing the 
@abs_builddir@ qualifier.


I'd put it the other way around: likely we should get rid of the
one use of @[EMAIL PROTECTED]


He, he.

Generally I prefer explicit over implicit (having the full paths make 
troubleshooting easier), but in this case you have the additional aspect 
of the lo_import operating relative to the client, while lo_export 
operates relative to the server. If you remove @abs_builddir@ on the 
first one, you might e.g. get problems like this:


  SELECT lo_export(loid, 'results/lotest.txt') FROM lotest_stash_values;
  ERROR:  could not create server file results/lotest.txt: No such
  file or directory

-J
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Technology Group
adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:[EMAIL PROTECTED]
title:Senior Engineer
tel;work:+47 73 84 21 10 
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
x-mozilla-html:FALSE
url:http://www.sun.com/
version:2.1
end:vcard


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] pg_regress: paths in largeobject test

2007-11-30 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes:
 Jorgen Austvik - Sun Norway wrote:
 Tom Lane wrote:
 I'd put it the other way around: likely we should get rid of the
 one use of @[EMAIL PROTECTED]

 Generally I prefer explicit over implicit (having the full paths make 
 troubleshooting easier), but in this case you have the additional aspect of 
 the lo_import operating relative to the client, while lo_export operates 
 relative to the server.

 I submit that the test is OK as it currently is.

Yeah, I hadn't thought about the different-paths aspect at the time of
making the above comment; but given that, it is correct as-is.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PATCHES] pg_regress: paths in largeobject test

2007-11-30 Thread Alvaro Herrera
Jorgen Austvik - Sun Norway wrote:
 Tom Lane wrote:
 Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes:
 I believe the results paths in line 139 and 144 are missing the 
 @abs_builddir@ qualifier.
 I'd put it the other way around: likely we should get rid of the
 one use of @[EMAIL PROTECTED]

 He, he.

 Generally I prefer explicit over implicit (having the full paths make 
 troubleshooting easier), but in this case you have the additional aspect of 
 the lo_import operating relative to the client, while lo_export operates 
 relative to the server.

I submit that the test is OK as it currently is.  The lo_export() call
is expanded by the server, which can be running anywhere -- hence the
need to use an absolute path.

Then we have \lo_import and \lo_export calls which are relative to the
client.  The client is already running in the regress builddir, so using
relative paths works fine.

If I try to run the client from another directory, it fails completely.
Exactly what is the problem you are trying to fix?

$ cd ..
$ pwd
/pgsql/build/00head/src/test
$ regress/pg_regress largeobject
(using postmaster on Unix socket, port 55432)
== dropping database regression ==
DROP DATABASE
== creating database regression ==
CREATE DATABASE
ALTER DATABASE
== running regression test queries==
test largeobject  ... /bin/sh: cannot open ./sql/largeobject.sql: No 
such file
diff: ./expected/largeobject.out: No such file or directory
diff: ./results/largeobject.out: No such file or directory
diff command failed with status 512: diff -w ./expected/largeobject.out 
./results/largeobject.out  ./results/largeobject.out.diff


-- 
Alvaro Herrerahttp://www.advogato.org/person/alvherre
The Postgresql hackers have what I call a NASA space shot mentality.
 Quite refreshing in a world of weekend drag racer developers.
(Scott Marlowe)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] pg_regress: paths in largeobject test

2007-11-29 Thread Tom Lane
Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes:
 I believe the results paths in line 139 and 144 are missing the 
 @abs_builddir@ qualifier.

I'd put it the other way around: likely we should get rid of the
one use of @[EMAIL PROTECTED]

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings