date:20060718

[HACKERS] float8 regression failure (HEAD, cygwin)

2006-07-18 Thread Adrian Maier


Hello,

While setting up a buildfarm installation for cygwin,  I've
uncountered the following
regression failure :

float8   ... FAILED

== pgsql.3132/src/test/regress/regression.diffs
*** ./expected/float8-small-is-zero.out Tue Jul 18 09:24:52 2006
--- ./results/float8.outTue Jul 18 09:53:42 2006
***
*** 13,29 
 SELECT '-10e400'::float8;
 ERROR:  -10e400 is out of range for type double precision
 SELECT '10e-400'::float8;
!  float8
! 
!  0
! (1 row)
!
 SELECT '-10e-400'::float8;
!  float8
! 
! -0
! (1 row)
!
 -- bad input
 INSERT INTO FLOAT8_TBL(f1) VALUES ('');
 ERROR:  invalid input syntax for type double precision: 
--- 13,21 
 SELECT '-10e400'::float8;
 ERROR:  -10e400 is out of range for type double precision
 SELECT '10e-400'::float8;
! ERROR:  10e-400 is out of range for type double precision
 SELECT '-10e-400'::float8;
! ERROR:  -10e-400 is out of range for type double precision
 -- bad input
 INSERT INTO FLOAT8_TBL(f1) VALUES ('');
 ERROR:  invalid input syntax for type double precision: 
***
*** 377,383 
--- 369,377 
 INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
 ERROR:  -10e400 is out of range for type double precision
 INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR:  10e-400 is out of range for type double precision
 INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR:  -10e-400 is out of range for type double precision
 -- maintain external table consistency across platforms
 -- delete all values and reinsert well-behaved ones
 DELETE FROM FLOAT8_TBL;
=

This happening on cygwin 1.5.20 (running on top of winXP),   gcc 3.4.4.


The entire check.log can be found here :
   http://www.newsoftcontrol.ro/~am/pgfarm/check.log
The other logs generated by the buildfarm can be found here:
  http://www.newsoftcontrol.ro/~am/pgfarm/



Cheers,
Adrian Maier

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

Re: [HACKERS] plPHP and plRuby

2006-07-18 Thread Thomas Hallgren

Marc G. Fournier wrote:

Actually it would be nice to have the not-included PLs present in
src/pl/ as their own directories with a README.TXT containing fetch and
build instructions

So we would have

src/pl/plphp/README.TXT
src/pl/pljava/README.TXT
src/pl/plj/README.TXT

and anybody looking for pl-s would find the info in a logical place

*That* idea I like ...

ISTM that a clear strategy for how to deal with core, contrib, add-ons, etc. is long overdue
and that's the reason why these discussions pop up over and over again. The question What
are the criterion's for core inclusion? has not yet been answered. I though PL/Java
fulfilled those criterion's but a new threshold for the #lines of code and a concern for
code in unmaintainable language made it impossible.

The result of an unclear strategy can be perceived as somewhat unjust. There seem to be a
very unanimous consensus that PL/pgsql belongs in core. Large object support, free text
search and some others also receive support by everyone. These add-ons clearly belong where
they are. The historical reasons to continuously include others are, IMHO, not so obvious
and the result undoubtedly creates first- and second class citizens in the module flora. The
split doesn't correlate very well with feature richness or popularity.

I have a suggestion that might help clearing things up a bit :-)

A couple of specialized teams need to be established (or rather, formalized since they
already exists to some extent) that can be thought of as core subsidiary's. The idea is
that such a team would take on the maintenance of one specialized area of PostgreSQL. Java,
for instance, is such an area. PostgreSQL has a huge number of Java users. They all use the
JDBC driver and a few use PL/Java. There's been talk about Eclipse tool support and some
will have an interest in XA-compliance in order to gain JTA support, etc. Today, it's
scattered all over the place. Other subsidiary teams should be formed around odbc (or .net
perhaps), php, ruby, replication/clustering, etc. to take control over those areas.

A very important part of my suggestion is that for the normal user, it would appear that
what a core subsidiary team contribute really is *part of* the database proper and not
something maintained by a third-party contributor or commercial vendor.

The team would maintain their own website (although all layout would be centralized), source
code control system, mailing list etc. but they would share a lot more of the PostgreSQL
infrastructure then what is shared today. Important things would be:

- Documentation. Inclusion of a subsidiary module should mean that some chapters are added
(automatically) to the user manual.

- Build farm support.
- Packaging and downloads
- Server infrastructure
- Seamless navigation from the PostgreSQL main web-site.

PgFoundry would live on like today, targeted on third-party modules and serving as an
incubator for modules that aim to be included in core or into one of its subsidiaries.

75 matches

Mail list logo