Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-14 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes:
 Reply from SCO:

 Indeed.  For inf, infinity, and nan, but not
 nan(digits), the pointer is left at the trailing
 matched character instead of the next.

 Moreover, checking our source history, it has been
 broken this way for nearly 12 years.  Couldn't you
 folks have noticed this bug a little sooner!?  :-)

Doesn't give one a warm feeling for the average level of error checking
in Unix programs, does it?

 I gather from this that it will be fixed in the first maint packs
 for 7.1.4.

Good.  I'd say we just leave it for that then.

Is there some way we can work around this?

I don't want to, because it would compromise the error checking.
For instance, if we hack the code to accept this behavior, then
it would also accept NaNN as soon as SCO fixes their bug.

The regression tests exist to discover platform bugs as well as
Postgres bugs.  In this case, I think having them fail on unpatched
SCO platforms is exactly what should happen.

If you want, you can send in a docs patch for FAQ_SCO to give
people a clue about it.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-14 Thread Larry Rosenman


--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane [EMAIL PROTECTED] wrote:

Larry Rosenman [EMAIL PROTECTED] writes:
Reply from SCO:

Indeed.  For inf, infinity, and nan, but not
nan(digits), the pointer is left at the trailing
matched character instead of the next.

Moreover, checking our source history, it has been
broken this way for nearly 12 years.  Couldn't you
folks have noticed this bug a little sooner!?  :-)
Doesn't give one a warm feeling for the average level of error checking
in Unix programs, does it?
nope



I gather from this that it will be fixed in the first maint packs
for 7.1.4.
Good.  I'd say we just leave it for that then.

Ok, but see below.


   Is there some way we can work around this?
I don't want to, because it would compromise the error checking.
For instance, if we hack the code to accept this behavior, then
it would also accept NaNN as soon as SCO fixes their bug.
Won't this change behaviour for

select 'NaN'::float8

etc such that Applications might fail?


The regression tests exist to discover platform bugs as well as
Postgres bugs.  In this case, I think having them fail on unpatched
SCO platforms is exactly what should happen.


If you want, you can send in a docs patch for FAQ_SCO to give
people a clue about it.
OK. See above comment, etc.


			regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


pgp0.pgp
Description: PGP signature


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 *** src/Makefile.global.in11 May 2004 21:57:14 -  1.182
 --- src/Makefile.global.in13 May 2004 23:03:12 -
 ***
 *** 177,182 
 --- 177,188 
 CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
   endif
  
 + # Unixware needs threads for everything that uses libpq
 + ifeq ($(PORTNAME),unixware)
 +   CFLAGS += $PTHREAD_CFLAGS
 + endif
 + 
 + 
   # Kind-of compilers
  
   YACC = @YACC@


Yech.  Isn't this what the Makefile.port files are for?  Makefile.global
should never contain any #ifdef port junk.


regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  *** src/Makefile.global.in  11 May 2004 21:57:14 -  1.182
  --- src/Makefile.global.in  13 May 2004 23:03:12 -
  ***
  *** 177,182 
  --- 177,188 
  CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
endif
   
  + # Unixware needs threads for everything that uses libpq
  + ifeq ($(PORTNAME),unixware)
  +   CFLAGS += $PTHREAD_CFLAGS
  + endif
  + 
  + 
# Kind-of compilers
   
YACC = @YACC@
 
 
 Yech.  Isn't this what the Makefile.port files are for?  Makefile.global
 should never contain any #ifdef port junk.

So we just add the thing in the template file?  Yea, I can do that.  I
did it there because Win32 already had something for libs.  Does the
template file get included in Makefile.global?  I didn't think so.

Part of the problem is we don't know if they have asked for threads at
the time we load the template file from configure, no?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 So we just add the thing in the template file?  Yea, I can do that.  I
 did it there because Win32 already had something for libs.  Does the
 template file get included in Makefile.global?  I didn't think so.

Not the template, the port-specific makefile.

regards, tom lane

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

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  So we just add the thing in the template file?  Yea, I can do that.  I
  did it there because Win32 already had something for libs.  Does the
  template file get included in Makefile.global?  I didn't think so.
 
 Not the template, the port-specific makefile.

Oh, I forgot about those.  Done.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman


--On Thursday, May 13, 2004 20:11:45 -0400 Bruce Momjian 
[EMAIL PROTECTED] wrote:

Good. I changed my commit to use your version.



Thanks!

Do we care about regression failures at this stage?

I have int4/int8/join failures (join is not new, and is
an order issue).
the int4/int8 have to do with NaN and Infinity i/o.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


pgp0.pgp
Description: PGP signature


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman


--On Thursday, May 13, 2004 20:49:28 -0400 Tom Lane [EMAIL PROTECTED] 
wrote:

Larry Rosenman [EMAIL PROTECTED] writes:
the int4/int8 have to do with NaN and Infinity i/o.
Those we care about.  I was hoping CVS tip would Just Work Everywhere
on that point, but evidently not :-(.  What do you get?  Did it work
better in 7.4?  Does Unixware support NaN/Infinity at all?
			regards, tom lane
Yes, we support NaN's and Inf.  From the fscanf manpage:
When matching floating numbers, the locale's decimal point character
  is taken to introduce a fractional portion, the sequences inf and
  infinity (case ignored) are taken to represent infinities, and the
  sequence nan[(m)] (case ignored), where the optional parenthesized m
  consists of zero or more alphanumeric or underscore (_) characters,
  are taken to represent NaNs (not-a-numbers). Note, however, that the
  locale's thousands' separator character will not be recognized as
  such.
I got:

*** ./expected/float4.out   Thu Mar 11 18:25:40 2004
--- ./results/float4.outThu May 13 19:08:18 2004
***
*** 33,67 
 ERROR:  invalid input syntax for type real: 1235
 -- special inputs
 SELECT 'NaN'::float4;
!  float4
! 
! NaN
! (1 row)
!
 SELECT 'nan'::float4;
!  float4
! 
! NaN
! (1 row)
!
 SELECT '   NAN  '::float4;
!  float4
! 
! NaN
! (1 row)
!
 SELECT 'infinity'::float4;
!   float4
! --
!  Infinity
! (1 row)
!
 SELECT '  -INFINiTY   '::float4;
!   float4
! ---
!  -Infinity
! (1 row)
!
 -- bad special inputs
 SELECT 'N A N'::float4;
 ERROR:  invalid input syntax for type real: N A N
--- 33,47 
 ERROR:  invalid input syntax for type real: 1235
 -- special inputs
 SELECT 'NaN'::float4;
! ERROR:  invalid input syntax for type real: NaN
 SELECT 'nan'::float4;
! ERROR:  invalid input syntax for type real: nan
 SELECT '   NAN  '::float4;
! ERROR:  invalid input syntax for type real:NAN  
 SELECT 'infinity'::float4;
! ERROR:  invalid input syntax for type real: infinity
 SELECT '  -INFINiTY   '::float4;
! ERROR:  invalid input syntax for type real:   -INFINiTY   
 -- bad special inputs
 SELECT 'N A N'::float4;
 ERROR:  invalid input syntax for type real: N A N
***
*** 70,88 
 SELECT ' INFINITYx'::float4;
 ERROR:  invalid input syntax for type real:  INFINITYx
 SELECT 'Infinity'::float4 + 100.0;
! ERROR:  type double precision value out of range: overflow
 SELECT 'Infinity'::float4 / 'Infinity'::float4;
!  ?column?
! --
!   NaN
! (1 row)
!
 SELECT 'nan'::float4 / 'nan'::float4;
!  ?column?
! --
!   NaN
! (1 row)
!
 SELECT '' AS five, FLOAT4_TBL.*;
  five | f1
 --+-
--- 50,60 
 SELECT ' INFINITYx'::float4;
 ERROR:  invalid input syntax for type real:  INFINITYx
 SELECT 'Infinity'::float4 + 100.0;
! ERROR:  invalid input syntax for type real: Infinity
 SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ERROR:  invalid input syntax for type real: Infinity
 SELECT 'nan'::float4 / 'nan'::float4;
! ERROR:  invalid input syntax for type real: nan
 SELECT '' AS five, FLOAT4_TBL.*;
  five | f1
 --+-
==

*** ./expected/float8.out	Fri Apr 23 15:32:20 2004
--- ./results/float8.out	Thu May 13 19:08:18 2004
***
*** 33,67 
 ERROR:  invalid input syntax for type double precision: 123   5
 -- special inputs
 SELECT 'NaN'::float8;
!  float8
! 
! NaN
! (1 row)
!
 SELECT 'nan'::float8;
!  float8
! 
! NaN
! (1 row)
!
 SELECT '   NAN  '::float8;
!  float8
! 
! NaN
! (1 row)
!
 SELECT 'infinity'::float8;
!   float8
! --
!  Infinity
! (1 row)
!
 SELECT '  -INFINiTY   '::float8;
!   float8
! ---
!  -Infinity
! (1 row)
!
 -- bad special inputs
 SELECT 'N A N'::float8;
 ERROR:  invalid input syntax for type double precision: N A N
--- 33,47 
 ERROR:  invalid input syntax for type double precision: 123   5
 -- special inputs
 SELECT 'NaN'::float8;
! ERROR:  invalid input syntax for type double precision: NaN
 SELECT 'nan'::float8;
! ERROR:  invalid input syntax for type double precision: nan
 SELECT '   NAN  '::float8;
! ERROR:  invalid input syntax for type double precision:NAN  
 SELECT 'infinity'::float8;
! ERROR:  invalid input syntax for type double precision: infinity
 SELECT '  -INFINiTY   '::float8;
! ERROR:  invalid input syntax for type double precision:  
-INFINiTY   
 -- bad special inputs
 SELECT 'N A N'::float8;
 ERROR:  invalid input syntax for type double precision: N A N
***
*** 70,88 
 SELECT ' INFINITYx'::float8;
 ERROR:  invalid input syntax for type double precision:  INFINITYx
 SELECT 'Infinity'::float8 + 100.0;
! ERROR:  type double precision value out of range: overflow
 SELECT 'Infinity'::float8 / 'Infinity'::float8;
!  ?column?
! --
!   

Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes:
 Does Unixware support NaN/Infinity at all?

 Yes, we support NaN's and Inf.

Hmph.  Apparently their strtod() has thought of some original new way to
misbehave on those inputs.  Would you mind tracing through float4in() or
float8in() to see exactly how it manages to fail?

regards, tom lane

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


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes:
 Where does it leave the ptr pointing to?

 $ ./test3
 ptr=8049682, points to N
 ptr=8049686, points to f

Indeed, they found an original new way to get it wrong.  Please point
out to them that the ptr is supposed to be advanced *past* the input.
Not to the last character of the input.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] threads stuff/UnixWare

2004-05-13 Thread Larry Rosenman


--On Thursday, May 13, 2004 21:35:43 -0400 Tom Lane [EMAIL PROTECTED] 
wrote:

Larry Rosenman [EMAIL PROTECTED] writes:
Where does it leave the ptr pointing to?

$ ./test3
ptr=8049682, points to N
ptr=8049686, points to f
Indeed, they found an original new way to get it wrong.  Please point
out to them that the ptr is supposed to be advanced *past* the input.
Not to the last character of the input.
Reported to my SCO contacts.  However, I guarantee this won't be fixed in
7.1.4 (the next release), as it just went Gold.
Also, I suspect 7.1.3 and below have the bug, and are prevalent.

And, I just proved it on my 7.1.2 (AKA OpenUNIX 8.0.0) system:

$ cc -O -o test3 test3.c
$ ./test3
num=nan
errno=0
ptr=8049682, points to N
num=inf
errno=0
ptr=8049686, points to f
$ uname -a
OpenUNIX lerlsof 5 8.0.0 i386 x86at Caldera UNIX_SVR5
$

			regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


pgp0.pgp
Description: PGP signature