Thread: ecpg test suite

ecpg test suite

From
Michael Meskes
Date:
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.

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!


Re: ecpg test suite

From
Andrew Dunstan
Date:

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


Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Tom Lane
Date:
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.shregression.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


Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Joachim Wieland
Date:
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
 


Re: ecpg test suite

From
Tom Lane
Date:
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 isdiff -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


Re: ecpg test suite

From
Joachim Wieland
Date:
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
 


Re: ecpg test suite

From
Tom Lane
Date:
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


Re: ecpg test suite

From
Tom Lane
Date:
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


Re: ecpg test suite

From
"Rocco Altier"
Date:
> 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



Re: ecpg test suite

From
"Rocco Altier"
Date:
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

> -----Original Message-----
> From: Michael Meskes [mailto:meskes@postgresql.org]
> Sent: Thursday, August 03, 2006 9:12 AM
> To: Rocco Altier
> Cc: Michael Meskes; PostgreSQL Hacker; joe@mcknight.de
> Subject: Re: [HACKERS] ecpg test suite
>
>
> 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!
>

Attachment

Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Michael Meskes
Date:
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
yourmachine? Or else could you build with debugging enabled on C level and trace down the function where the out of
memoryoccurs?
 

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

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


Re: ecpg test suite

From
Tom Lane
Date:
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
(shouldbe error!): 1 timestamp_defmt_asc(abc    18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
pmin 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
(shouldbe error!): 1 timestamp_defmt_asc(abc    18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
theyear 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
 


Re: ecpg test suite

From
Tom Lane
Date:
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
(shouldbe error!): 1 timestamp_defmt_asc(abc    18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
pmin 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
(shouldbe error!): 1 timestamp_defmt_asc(abc    18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
theyear 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


Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Tom Lane
Date:
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


Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Michael Meskes
Date:
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!


Re: ecpg test suite

From
Tom Lane
Date:
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


Re: ecpg test suite

From
Tom Lane
Date:
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_dataline 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 47: RESULT: f offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 47: RESULT: f offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 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_dataline 34: RESULT: two offset: -1 array: Yes
 
        regards, tom lane


Re: ecpg test suite

From
Joachim Wieland
Date:
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
 


Re: ecpg test suite

From
"Merlin Moncure"
Date:
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


Re: ecpg test suite

From
Joachim Wieland
Date:
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
 


Re: ecpg test suite

From
"Merlin Moncure"
Date:
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