Win32 regression tests

Hi all,

the win32 port is now at the stage (with the pending patches) where a
surprising number of the tests pass (or would pass if not for the
differences in %e/%g printing and the pre-1970 localtime issues, discussed
previously).

However, a number of tests fail purely because, for some reason, ERROR
messages seem to get printed out at the end of the test, instead of where
expected, and sometimes with an extra blank line. I've included a few
examples below.

Anyway care to hazard a guess as to what the cause could be, and how to
correct?

Cheers,
Claudio

*** ./expected/boolean.out Sun Sep 28 23:10:44 2003
--- ./results/boolean.out Thu Feb 5 13:53:22 2004
***************
*** 112,118 ****
-- For pre-v6.3 this evaluated to false - thomas 1997-10-23
INSERT INTO BOOLTBL2 (f1)
VALUES (bool 'XXX');
- ERROR: invalid input syntax for type boolean: "XXX"
-- BOOLTBL2 should be full of false's at this point
SELECT '' AS f_4, BOOLTBL2.*;
f_4 | f1
--- 125,130 ----
***************
*** 277,279 ****
--- 302,305 ----
--
DROP TABLE BOOLTBL1;
DROP TABLE BOOLTBL2;
+ ERROR: invalid input syntax for type boolean: "XXX"

======================================================================

*** ./expected/char_1.out Tue May 14 23:05:43 2002
--- ./results/char.out Thu Feb 5 13:53:22 2004
***************
*** 23,29 ****
INSERT INTO CHAR_TBL (f1) VALUES ('');
-- try char's of greater than 1 length
INSERT INTO CHAR_TBL (f1) VALUES ('cd');
- ERROR: value too long for type character(1)
INSERT INTO CHAR_TBL (f1) VALUES ('c ');
SELECT '' AS seven, CHAR_TBL.*;
seven | f1
--- 24,29 ----
***************
*** 109,115 ****
INSERT INTO CHAR_TBL (f1) VALUES ('ab');
INSERT INTO CHAR_TBL (f1) VALUES ('abcd');
INSERT INTO CHAR_TBL (f1) VALUES ('abcde');
- ERROR: value too long for type character(4)
INSERT INTO CHAR_TBL (f1) VALUES ('abcd ');
SELECT '' AS four, CHAR_TBL.*;
four | f1
--- 116,121 ----
***************
*** 120,122 ****
--- 126,131 ----
| abcd
(4 rows)

+
+ ERROR: value too long for type character(1)
+ ERROR: value too long for type character(4)

======================================================================

*** ./expected/varchar_1.out Tue May 14 23:05:43 2002
--- ./results/varchar.out Thu Feb 5 13:53:23 2004
***************
*** 12,18 ****
INSERT INTO VARCHAR_TBL (f1) VALUES ('');
-- try varchar's of greater than 1 length
INSERT INTO VARCHAR_TBL (f1) VALUES ('cd');
- ERROR: value too long for type character varying(1)
INSERT INTO VARCHAR_TBL (f1) VALUES ('c ');
SELECT '' AS seven, VARCHAR_TBL.*;
seven | f1
--- 12,17 ----
***************
*** 98,104 ****
INSERT INTO VARCHAR_TBL (f1) VALUES ('ab');
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcd');
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcde');
- ERROR: value too long for type character varying(4)
INSERT INTO VARCHAR_TBL (f1) VALUES ('abcd ');
SELECT '' AS four, VARCHAR_TBL.*;
four | f1
--- 104,109 ----
***************
*** 109,111 ****
--- 114,119 ----
| abcd
(4 rows)

+
+ ERROR: value too long for type character varying(1)
+ ERROR: value too long for type character varying(4)

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> However, a number of tests fail purely because, for some reason, ERROR
> messages seem to get printed out at the end of the test, instead of where
> expected, and sometimes with an extra blank line. I've included a few
> examples below.

> Anyway care to hazard a guess as to what the cause could be, and how to
> correct?

Lack of fflush(stderr) maybe? On Unix systems stderr is line-buffered
and so it's seldom necessary to fflush it, but perhaps Windows gets this
wrong (yawn...).

regards, tom lane

Tom Lane wrote:

>Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
>
>
>>However, a number of tests fail purely because, for some reason, ERROR
>>messages seem to get printed out at the end of the test, instead of where
>>expected, and sometimes with an extra blank line. I've included a few
>>examples below.
>>
>>
>
>
>
>>Anyway care to hazard a guess as to what the cause could be, and how to
>>correct?
>>
>>
>
>Lack of fflush(stderr) maybe? On Unix systems stderr is line-buffered
>and so it's seldom necessary to fflush it, but perhaps Windows gets this
>wrong (yawn...).
>
>
>
Or unbuffered. On Linux "man setbuf " says:

The standard error stream stderr is always unbuffered by default.

Perhaps on Windows we should put a call to "setbuf(stderr,NULL)"
somewhere right at the beginning of each program.

cheers

andrew