ecpg test suite

Michael Meskes wrote:

I'm in the process of committing the first version of the ecpg
regression test suite to CVS. This is not exactly finished work, but it
shows OK on all test on my machine and on Joachim's machine. The tests
need to be tweaked some before it's finished, but I'd like to hear about
what others are seeing soon enough to be able to fix bugs before 8.2.

Just run "make check" in src/interfaces/ecpg and tell us if there is
some test that fails.

This should be set up so that we can easily run it on the buildfarm
automated setup - the simplest way would probably be with an
installcheck target. Feel free to ping me if you need help in making it
buildfarm friendly.

cheers

andrew

Hi,

I just committed some changes by Joachim that should reduce the problems
and the differences by a large margin. Could you please rerun the test
and send us the regression.diff? Thanks a lot in advance.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes@postgresql.org> writes:

I just committed some changes by Joachim that should reduce the problems
and the differences by a large margin. Could you please rerun the test
and send us the regression.diff? Thanks a lot in advance.

While init.pgc no longer fails outright, it still generates a pile of
unsightly compiler warnings, eg on Fedora 5 (gcc 4.1.1)

dyntest.pgc:66: WARNING: nullable is always 1
dyntest2.pgc:72: WARNING: nullable is always 1
init.pgc:8: warning: no previous prototype for 'fa'
init.pgc:15: warning: no previous prototype for 'fb'
init.pgc:22: warning: no previous prototype for 'fc'
init.pgc:28: warning: no previous prototype for 'fd'
init.pgc:34: warning: no previous prototype for 'fe'
init.pgc:40: warning: no previous prototype for 'sqlnotice'
init.pgc: In function 'main':
init.pgc:76: warning: unused variable 'f'
init.pgc:73: warning: unused variable 'iax'
init.pgc:72: warning: unused variable 'iay'
init.pgc:71: warning: unused variable 'h'
init.pgc:70: warning: unused variable 'c'
init.pgc:69: warning: unused variable 'e'
init.pgc:67: warning: unused variable 'j'
init.pgc:66: warning: unused variable 'i'
init.pgc:65: warning: unused variable 'g'
init.pgc:64: warning: unused variable 'd'
init.pgc:63: warning: unused variable 'b2'
init.pgc:62: warning: unused variable 'b'
init.pgc:61: warning: unused variable 'a'
init.pgc:69: warning: 'y' is used uninitialized in this function
test_informix.pgc: In function 'main':
test_informix.pgc:20: warning: implicit declaration of function 'exit'
test_informix.pgc:20: warning: incompatible implicit declaration of built-in function 'exit'

I find this really unacceptable. There is no other part of the Postgres
tree besides ecpg that generates any warnings at all.

As for the actual test, I get:

$ make check
...
if [ all = clean ]; then rm -f results/*.stdout results/*.stderr results/*.c; rm
-rf tmp_check/; rm -f log/*.log; rm -f pg_regress.inc.sh regression.diff; fi
sh ./pg_regress.sh --dbname=regress1 --debug --temp-install --top-builddir=../.
./../.. --temp-port=55444 --listen-on-tcp --multibyte=SQL_ASCII --load-language=
plpgsql
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 55444 with pid 10754
============== creating database "regress1" ==============
CREATE DATABASE
============== installing plpgsql ==============
============== creating database "connectdb" ==============
CREATE DATABASE
============== installing plpgsql ==============
============== running regression test queries ==============
/home/tgl/pgsql/src/interfaces/ecpg/test/./tmp_check/install//home/tgl/testversion/bin/createuser -R -S -D -q regressuser1
/home/tgl/pgsql/src/interfaces/ecpg/test/./tmp_check/install//home/tgl/testversion/bin/createuser -R -S -D -q connectuser
testing connect/test1.pgc ... FAILED (log, output, source)
testing connect/test2.pgc ... FAILED (log, output, source)
testing connect/test3.pgc ... FAILED (log, output, source)
testing connect/test4.pgc ... FAILED (log, output, source)
testing compat_informix/test_informix.pgc ... FAILED (log, output, source)
testing compat_informix/test_informix2.pgc ... FAILED (log, output, source)
testing complex/test1.pgc ... FAILED (log, output, source)
testing complex/test2.pgc ... FAILED (log, output, source)
testing complex/test3.pgc ... FAILED (log, output, source)
testing complex/test4.pgc ... FAILED (log, output, source)
testing complex/test5.pgc ... FAILED (log, output, source)
testing errors/init.pgc ... FAILED (log, output, source)
testing pgtypeslib/dt_test.pgc ... FAILED (log, output, source)
testing pgtypeslib/dt_test2.pgc ... FAILED (log, output, source)
testing pgtypeslib/num_test.pgc ... FAILED (log, output, source)
testing sql/code100.pgc ... FAILED (log, output, source)
testing sql/copystdout.pgc ... FAILED (log, output, source)
testing sql/define.pgc ... FAILED (log, output, source)
testing sql/desc.pgc ... FAILED (log, output, source)
testing sql/dynalloc.pgc ... FAILED (log, output, source)
testing sql/dynalloc2.pgc ... FAILED (log, output, source)
testing sql/dyntest.pgc ... FAILED (log, output, source)
testing sql/dyntest2.pgc ... FAILED (log, output, source)
testing sql/func.pgc ... FAILED (log, output, source)
testing sql/indicators.pgc ... FAILED (log, output, source)
testing sql/quote.pgc ... FAILED (log, output, source)
testing sql/show.pgc ... FAILED (log, output, source)
testing thread/thread.pgc ... FAILED (log, output, source)
testing thread/thread_implicit.pgc ... FAILED (log, output, source)
diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.
make[1]: Leaving directory `/home/tgl/pgsql/src/interfaces/ecpg/test'

Regression.diffs is empty, possibly because of the incorrect
diff invocation hinted at by the last message, but looking into
the results directory makes it look like you've not got everything on
the same page about which port number to use:

[NO_PID]: connect: could not open database connectdb on localhost port 55432 for user connectuser in line 41
could not connect to server: Connection refused
Is the server running on host "localhost" and accepting
TCP/IP connections on port 55432?

That's not the port the temp postmaster is listening on; I suspect
you've got some hard-wired assumption in there that the user hasn't
specified a nonstandard --port option to configure.

I find it disturbing that the regression test script doesn't mention having
shut down the temp postmaster, too.

regards, tom lane

On Thu, Aug 03, 2006 at 09:47:27AM -0400, Tom Lane wrote:

While init.pgc no longer fails outright, it still generates a pile of
unsightly compiler warnings, eg on Fedora 5 (gcc 4.1.1)
...
I find this really unacceptable. There is no other part of the Postgres
tree besides ecpg that generates any warnings at all.

Tom, keep in mind that we are working on this. The tests were originally
just some files I used to develop with. We are now making them become
part of the source tree. The warnings should be gone by now, except for
the ECPG warning that is supposed to come out. Maybe we remove that
line.

Joachim didn't want me to commit his SoC stuff before he finishes work,
but I felt this is the better way because we get some testing on other
architectures/OSes so everything should be up and running come release
time.

diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.

Strange, works well on my Linux system. However, I tried correcting the
option but I'm unsure if it works for you now since both versions worked
for me.

Regression.diffs is empty, possibly because of the incorrect
diff invocation hinted at by the last message, but looking into
the results directory makes it look like you've not got everything on
the same page about which port number to use:

[NO_PID]: connect: could not open database connectdb on localhost port 55432 for user connectuser in line 41
could not connect to server: Connection refused
Is the server running on host "localhost" and accepting
TCP/IP connections on port 55432?

That's not the port the temp postmaster is listening on; I suspect
you've got some hard-wired assumption in there that the user hasn't
specified a nonstandard --port option to configure.

I find it disturbing that the regression test script doesn't mention having
shut down the temp postmaster, too.

No idea. Joachim?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote:

diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.

Strange, works well on my Linux system. However, I tried correcting the
option but I'm unsure if it works for you now since both versions worked
for me.

This got introduced by Rocco's Makefile patch, it worked for me, so I
thought it's fine. Rocco, your AIX box will work with only diff -c as well,
won't it?

[NO_PID]: connect: could not open database connectdb on localhost port 55432 for user connectuser in line 41
could not connect to server: Connection refused
Is the server running on host "localhost" and accepting
TCP/IP connections on port 55432?

That's not the port the temp postmaster is listening on; I suspect
you've got some hard-wired assumption in there that the user hasn't
specified a nonstandard --port option to configure.

I find it disturbing that the regression test script doesn't mention having
shut down the temp postmaster, too.

No idea. Joachim?

Yes, it's hardcoded but in just one file. Only one of the connect-Tests does
tcp/ip connects. This can't be changed by a simple #define nor exec sql
define, so I added a template file and replaced the port number with sed.

Michael, in a few minutes I'll send you a patch that fixes all of Tom's
suggestions (however you might have done parts of it already by yourself,
like the diff options and the warnings...).

Joachim

--
Joachim Wieland joe@mcknight.de
GPG key available

Joachim Wieland <joe@mcknight.de> writes:

diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.

This got introduced by Rocco's Makefile patch, it worked for me, so I
thought it's fine. Rocco, your AIX box will work with only diff -c as well,
won't it?

The spelling we've used for many years is
diff -w -C3
Is there a reason to change from that?

Yes, it's hardcoded but in just one file. Only one of the connect-Tests does
tcp/ip connects. This can't be changed by a simple #define nor exec sql
define, so I added a template file and replaced the port number with sed.

At least from my perspective, it would be good if there were a way to
run the regression tests without any use of TCP ports. The problem is
that Red Hat's build system tends to try to build 32-bit and 64-bit
variants of the same architecture concurrently in different chroots
on the same machine. Tests using unix sockets work fine in this
environment, tests using TCP sockets conflict and fail. If there's
no way to run an ecpg test without TCP then I'll never be able to enable
ecpg regression tests in Red Hat RPMs.

regards, tom lane

On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:

The spelling we've used for many years is
diff -w -C3

I found only -w, but will append -C3 as well.

Is there a reason to change from that?

No.

At least from my perspective, it would be good if there were a way to
run the regression tests without any use of TCP ports.

It's not necessary, ecpglib uses libpq as any other program, however it does
its own parsing of the connect options and there are quite a few different
formats you could use so it would be nice to cover that by a few small
tests.

Do you see a possibility to select what test should be run? Maybe no tcp
connections by default but with an additional make-target "checktcp"?

Joachim

--
Joachim Wieland joe@mcknight.de
GPG key available

Joachim Wieland <joe@mcknight.de> writes:

On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:

At least from my perspective, it would be good if there were a way to
run the regression tests without any use of TCP ports.

Do you see a possibility to select what test should be run? Maybe no tcp
connections by default but with an additional make-target "checktcp"?

That would work for me.

Note there are other reasons besides my Red-Hat-specific problem for not
wanting to enable TCP connections during regression tests, for instance
* on some platforms they will fail due to aggressive kernel packet
filtering
* one might not care to expose a postmaster running with auth-method
"trust" to the network, even for just a few seconds.

regards, tom lane

Joachim Wieland <joe@mcknight.de> writes:

On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:

The spelling we've used for many years is
diff -w -C3

I found only -w, but will append -C3 as well.

Careful, there are two different usages: we use -C3 to generate the
"pretty" report to regression.diffs, but not in the preliminary testing
step.

regards, tom lane

From: Joachim Wieland [mailto:joe@mcknight.de]
Sent: Thursday, August 03, 2006 11:23 AM
To: Tom Lane; Michael Meskes; Rocco Altier; PostgreSQL Hacker
Subject: Re: [HACKERS] ecpg test suite

On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote:

diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.

Strange, works well on my Linux system. However, I tried

correcting the

option but I'm unsure if it works for you now since both

versions worked

for me.

This got introduced by Rocco's Makefile patch, it worked for me, so I
thought it's fine. Rocco, your AIX box will work with only
diff -c as well,
won't it?

I had used -c to replace the -u.

The '-c3' does not work on my machine, but '-C3' does, so I think we
should go with that.

Thanks,
-rocco

On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:

The spelling we've used for many years is
diff -w -C3
Is there a reason to change from that?

This was my fault. When I changed the options I mixed upper and
lowercase and used lowercase 'c' instead of uppercase 'C'. That should
be fixed now.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Here is my updated regression.diff.

Like Tom, I was running with my server configured to run on 5678,
instead of 5432, so it seems like the test is using a wrong port number
somewhere.

I changed my local pg_regress.sh to use -C3 on the diffs, until we
figure out what the final form of that will be.

BTW, I do have --enable-integer-datetimes configured for this machine,
which might explain the timestamp differences.

Thanks,
-rocco

On Thu, Aug 03, 2006 at 02:56:15PM -0400, Rocco Altier wrote:

BTW, I do have --enable-integer-datetimes configured for this machine,
which might explain the timestamp differences.

Yes, that might be the reason. What effect does it have if you run the
backend regression suite?

The remaining problems are:

- out of memory in complex/test4: This needs some debugging on an AIX
machine. Is it possible for me to get access to your machine? Or else
could you build with debugging enabled on C level and trace down the
function where the out of memory occurs?

- different value in sql/desc: This is strange as the stderr output
seems to be the same. This could be a memory problem too.

- sql/dyntest2 with a different output: Strange again as the log output
seems to be identical.

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Here's the ecpg regression test diffs as of CVS tip on an HPUX box.

regards, tom lane

*** expected/complex-test4.stdout	Wed Aug  2 10:14:02 2006
--- results//complex-test4.stdout	Fri Aug  4 10:12:19 2006
***************
*** 1,4 ****
! Found f=14,070000 text=0123456789 b=1
  Found a[0] = 9
  Found a[1] = 8
  Found a[2] = 7
--- 1,4 ----
! Found f=14.070000 text=0123456789 b=1
  Found a[0] = 9
  Found a[1] = 8
  Found a[2] = 7
*** expected/pgtypeslib-dt_test.stderr	Thu Aug  3 09:24:58 2006
--- results//pgtypeslib-dt_test.stderr	Fri Aug  4 10:12:20 2006
***************
*** 22,28 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
  [NO_PID]: sqlca: code: 0, state: 00000
--- 22,28 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
  [NO_PID]: sqlca: code: 0, state: 00000
*** expected/pgtypeslib-dt_test.stdout	Wed Aug  2 10:14:03 2006
--- results//pgtypeslib-dt_test.stdout	Fri Aug  4 10:12:20 2006
***************
*** 41,47 ****
     18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
  timestamp_defmt_asc(abc
     18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , (null)) = 1980-04-12 03:49:44, error: 0
  timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
  timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
  timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0
--- 41,47 ----
     18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
  timestamp_defmt_asc(abc
     18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , ) = 1980-04-12 03:49:44, error: 0
  timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
  timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
  timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0
*** expected/sql-dyntest2.stderr	Fri Aug  4 08:50:50 2006
--- results//sql-dyntest2.stderr	Fri Aug  4 10:12:23 2006
***************
*** 58,64 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
--- 58,64 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
***************
*** 198,204 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
--- 198,204 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
*** expected/sql-dyntest2.stdout	Fri Aug  4 08:50:50 2006
--- results//sql-dyntest2.stdout	Fri Aug  4 10:12:23 2006
***************
*** 4,10 ****
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10297">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
--- 4,10 ----
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10300">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
***************
*** 22,28 ****
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10300">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
--- 22,28 ----
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10303">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1

BTW, I tried building with HP's cc instead of gcc, and got
slightly different regression failures (same HPUX/HPPA machine):

*** expected/complex-test4.stdout	Wed Aug  2 10:14:02 2006
--- results//complex-test4.stdout	Fri Aug  4 12:56:13 2006
***************
*** 1,4 ****
! Found f=14,070000 text=0123456789 b=1
  Found a[0] = 9
  Found a[1] = 8
  Found a[2] = 7
--- 1,4 ----
! Found f=14.070000 text=0123456789 b=1
  Found a[0] = 9
  Found a[1] = 8
  Found a[2] = 7
*** expected/pgtypeslib-dt_test.stderr	Thu Aug  3 09:24:58 2006
--- results//pgtypeslib-dt_test.stderr	Fri Aug  4 12:56:14 2006
***************
*** 22,28 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
  [NO_PID]: sqlca: code: 0, state: 00000
--- 22,28 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
  [NO_PID]: sqlca: code: 0, state: 00000
*** expected/pgtypeslib-dt_test.stdout	Wed Aug  2 10:14:03 2006
--- results//pgtypeslib-dt_test.stdout	Fri Aug  4 12:56:14 2006
***************
*** 41,47 ****
     18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
  timestamp_defmt_asc(abc
     18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , (null)) = 1980-04-12 03:49:44, error: 0
  timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
  timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
  timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0
--- 41,47 ----
     18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
  timestamp_defmt_asc(abc
     18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , ) = 1980-04-12 03:49:44, error: 0
  timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
  timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
  timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0
*** expected/sql-desc.stdout	Thu Aug  3 09:24:58 2006
--- results//sql-desc.stdout	Fri Aug  4 12:56:15 2006
***************
*** 1,4 ****
  output = 1
! val1=1 (ind1: 0) val2='one' (ind2: 0)
  val1=2 val2=null
  val1=2 val2=null
--- 1,4 ----
  output = 1
! val1=654311425 (ind1: 0) val2='one' (ind2: 0)
  val1=2 val2=null
  val1=2 val2=null
*** expected/sql-dyntest2.stderr	Fri Aug  4 08:50:50 2006
--- results//sql-dyntest2.stderr	Fri Aug  4 12:56:17 2006
***************
*** 58,64 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
--- 58,64 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
***************
*** 198,204 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
--- 198,204 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
*** expected/sql-dyntest2.stdout	Fri Aug  4 08:50:50 2006
--- results//sql-dyntest2.stdout	Fri Aug  4 12:56:17 2006
***************
*** 4,10 ****
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10297">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
--- 4,10 ----
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10300">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
***************
*** 22,28 ****
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10300">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1
--- 22,28 ----
  	= <"_RETURN">
   2	ev_class (type: -26 length: -5 precision: -1 scale: 65531
  	octet_length: 4 returned_octet_length: 5)
! 	= <"10303">
   3	ev_attr (type: 5 length: -5 precision: -1 scale: 65531
  	octet_length: 2 returned_octet_length: 2)
  	= -1

regards, tom lane

On Fri, Aug 04, 2006 at 12:59:35PM -0400, Tom Lane wrote:

*** expected/complex-test4.stdout	Wed Aug  2 10:14:02 2006
--- results//complex-test4.stdout	Fri Aug  4 12:56:13 2006
***************
*** 1,4 ****
! Found f=14,070000 text=0123456789 b=1
Found a[0] = 9
Found a[1] = 8
Found a[2] = 7
--- 1,4 ----
! Found f=14.070000 text=0123456789 b=1
Found a[0] = 9
Found a[1] = 8
Found a[2] = 7

Locale problem. Fixed by setting locale to C.

*** expected/pgtypeslib-dt_test.stderr	Thu Aug  3 09:24:58 2006
--- results//pgtypeslib-dt_test.stderr	Fri Aug  4 12:56:14 2006
***************
*** 22,28 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
[NO_PID]: sqlca: code: 0, state: 00000
--- 22,28 ----

Some types have different internal sizes on different systems. I wonder
what we do with these difference as a log file usually prints this info
which is important for debugging sometimes.

*** expected/pgtypeslib-dt_test.stdout	Wed Aug  2 10:14:03 2006
--- results//pgtypeslib-dt_test.stdout	Fri Aug  4 12:56:14 2006
***************
*** 41,47 ****
18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
timestamp_defmt_asc(abc
18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , (null)) = 1980-04-12 03:49:44, error: 0
timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0
--- 41,47 ----
18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1
timestamp_defmt_asc(abc
18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1
! timestamp_defmt_asc(1980-04-12 3:49:44      , ) = 1980-04-12 03:49:44, error: 0
timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0
timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0
timestamp_defmt_asc(  1976, July 14. Time: 9:15am, %Y,   %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0

Different compiler gets different output for NULL value. Fixed.

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes@postgresql.org> writes:

Some types have different internal sizes on different systems. I wonder
what we do with these difference as a log file usually prints this info
which is important for debugging sometimes.

If there's only a small number of possibilities, you could fix it by
treating these as if they were locale differences --- that is, provide
multiple expected files test.out, test_1.out, etc.

regards, tom lane

On Sat, Aug 05, 2006 at 01:14:25PM -0400, Tom Lane wrote:

If there's only a small number of possibilities, you could fix it by
treating these as if they were locale differences --- that is, provide
multiple expected files test.out, test_1.out, etc.

Frankly I have no idea. I was thinking about removing this bit of
information from the log if it is a regression test run because it
doesn't bring us more information in terms of regresseion testing.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

We changed some things that should remove most of the differences you
had.

Two other diffs looked like you had an older version of ecpglib running. Could that be?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes@postgresql.org> writes:

We changed some things that should remove most of the differences you
had.

Two other diffs looked like you had an older version of ecpglib running. Could that be?

Bingo --- I had been doing "make clean", "make all", "make check".
It seems this is managing to invoke the installed version of ecpglib
not the just-built version, probably because of the rpath switches
we use on HPUX. With "make install" before "make check", I get a
clean pass with this morning's CVS tip (using gcc ... will try HP's
cc in a bit).

You really oughta support "make installcheck" anyway; aside from being
less vulnerable to this issue, it's a lot less overhead to run.

regards, tom lane

I wrote:

With "make install" before "make check", I get a
clean pass with this morning's CVS tip (using gcc ... will try HP's
cc in a bit).

Further results:

* The vulnerability to using a previously installed ecpglib exists in
our default Linux configuration as well as HPUX.

* Still fails with HP's cc on HPUX:

*** expected/sql-desc.stdout	Thu Aug  3 09:24:58 2006
--- results//sql-desc.stdout	Tue Aug  8 09:03:35 2006
***************
*** 1,4 ****
  output = 1
! val1=1 (ind1: 0) val2='one' (ind2: 0)
  val1=2 val2=null
  val1=2 val2=null
--- 1,4 ----
  output = 1
! val1=654311425 (ind1: 0) val2='one' (ind2: 0)
  val1=2 val2=null
  val1=2 val2=null

* Still fails with gcc on x86_64:

*** expected/pgtypeslib-num_test2.stdout	Mon Aug  7 09:17:02 2006
--- results//pgtypeslib-num_test2.stdout	Tue Aug  8 08:51:06 2006
***************
*** 53,59 ****
  (no errno set) - num[4,3]: 5924900000.0
  (no errno set) - num[4,4]: 5924900000.00
  (no errno set) - num[4,5]: 0.00
! (errno == PGTYPES_NUM_OVERFLOW) - num[4,6]: 0 (r: -1)
  (errno == PGTYPES_NUM_OVERFLOW) - num[4,8]: 0 (r: -1)
  (errno == PGTYPES_NUM_OVERFLOW) - num[4,10]: 5924900000.0000000 (r: 0)
  (no errno set) - num[4,11]: 5924900000.00 (cmp: 0)
--- 53,60 ----
  (no errno set) - num[4,3]: 5924900000.0
  (no errno set) - num[4,4]: 5924900000.00
  (no errno set) - num[4,5]: 0.00
! (no errno set) - num[4,6]: 5924900000 (r: 0)
! (no errno set) - num[4,7]: 5924900000.00 (cmp: 0)
  (errno == PGTYPES_NUM_OVERFLOW) - num[4,8]: 0 (r: -1)
  (errno == PGTYPES_NUM_OVERFLOW) - num[4,10]: 5924900000.0000000 (r: 0)
  (no errno set) - num[4,11]: 5924900000.00 (cmp: 0)
*** expected/sql-dynalloc.stderr	Tue Aug  8 08:43:33 2006
--- results//sql-dynalloc.stderr	Tue Aug  8 08:51:06 2006
***************
*** 34,75 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 43: allocating 21 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 43: RESULT:  offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 4
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 44: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 5
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 45: allocating 22 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 45: RESULT: c    offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 45: RESULT: c    offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 6
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 46: allocating 70 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 7
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 47: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 47: RESULT: t offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 47: RESULT: f offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 9
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 50: allocating 46 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 50: RESULT: 2001:4f8:3:ba:2e0:81ff:fe22:d1f1 offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 50: RESULT:  offset: -1 array: Yes
--- 34,75 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 3
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 43: allocating 33 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 43: RESULT:  offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 4
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 44: allocating 28 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 5
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 45: allocating 34 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 45: RESULT: c    offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 45: RESULT: c    offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 6
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 46: allocating 82 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 7
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 47: allocating 28 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 47: RESULT: t offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 47: RESULT: f offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 9
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 50: allocating 58 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 50: RESULT: 2001:4f8:3:ba:2e0:81ff:fe22:d1f1 offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 50: RESULT:  offset: -1 array: Yes
*** expected/sql-dynalloc2.stderr	Tue Aug  8 08:43:33 2006
--- results//sql-dynalloc2.stderr	Tue Aug  8 08:51:06 2006
***************
*** 54,60 ****
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 34: allocating 49 bytes for 6 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 34: RESULT: one offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 34: RESULT: two offset: -1 array: Yes
--- 54,60 ----
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_desc: reading items for tuple 2
  [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 34: allocating 77 bytes for 6 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 34: RESULT: one offset: -1 array: Yes
  [NO_PID]: sqlca: code: 0, state: 00000
  [NO_PID]: ECPGget_data line 34: RESULT: two offset: -1 array: Yes

regards, tom lane

On Tue, Aug 08, 2006 at 09:09:17AM -0400, Tom Lane wrote:

* The vulnerability to using a previously installed ecpglib exists in
our default Linux configuration as well as HPUX.

On my linux box the libs get built with -rpath as well and I think that
there's no portable way to remove it once it is in. Doesn't the backend
regression test (using psql) suffer from the same problem with libpq?

Joachim

--
Joachim Wieland joe@mcknight.de
GPG key available

On 8/2/06, Michael Meskes <meskes@postgresql.org> wrote:

I'm in the process of committing the first version of the ecpg
regression test suite to CVS. This is not exactly finished work, but it
shows OK on all test on my machine and on Joachim's machine. The tests
need to be tweaked some before it's finished, but I'd like to hear about
what others are seeing soon enough to be able to fix bugs before 8.2.

Just run "make check" in src/interfaces/ecpg and tell us if there is
some test that fails.

just fyi:
did a cvs update around 12pm est today and am getting a make error:

make[4]: Entering directory `/usr/src/pgsql/src/interfaces/ecpg/test'
sed -e 's,@bindir@,/usr/local/pgsql/bin,g' \
-e 's,@libdir@,/usr/local/pgsql/lib,g' \
-e 's,@pkglibdir@,/usr/local/pgsql/lib,g' \
-e 's,@datadir@,/usr/local/pgsql/share,g' \
-e 's/@VERSION@/8.2devel/g' \
-e 's/@host_tuple@/i686-pc-linux-gnu/g' \
-e 's,@GMAKE@,make,g' \
-e 's/@enable_shared@/yes/g' \
-e 's/@GCC@/yes/g' \
pg_regress.inc.sh.in >pg_regress.inc.sh
make -C connect all
make: *** connect: No such file or directory. Stop.
make: Entering an unknown directorymake: Leaving an unknown
directorymake[4]: *** [all] Error 2
make[4]: Leaving directory `/usr/src/pgsql/src/interfaces/ecpg/test'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/pgsql/src/interfaces/ecpg'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/pgsql/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/pgsql/src'
make: *** [all] Error 2

Merlin,

On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote:

just fyi:
did a cvs update around 12pm est today and am getting a make error:

make -C connect all
make: *** connect: No such file or directory. Stop.
make: Entering an unknown directorymake: Leaving an unknown
directorymake[4]: *** [all] Error 2

You don't have ecpg/test/connect/ ?

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/connect/

Joachim

--
Joachim Wieland joe@mcknight.de
GPG key available

On 8/8/06, Joachim Wieland <joe@mcknight.de> wrote:

Merlin,

On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote:

just fyi:
did a cvs update around 12pm est today and am getting a make error:

make -C connect all
make: *** connect: No such file or directory. Stop.
make: Entering an unknown directorymake: Leaving an unknown
directorymake[4]: *** [all] Error 2

You don't have ecpg/test/connect/ ?

my fault...needed to to cvs update -d

regards,
merlin