Re: [HACKERS] NT port of PGSQL - success - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] NT port of PGSQL - success |
Date | |
Msg-id | 199810081536.LAA09240@candle.pha.pa.us Whole thread Raw |
In response to | RE: [HACKERS] NT port of PGSQL - success (Horak Daniel <horak@mmp.plzen-city.cz>) |
List | pgsql-hackers |
> > > changes are version independent. The main difference from > > other port is > > > the renamed system table pg_version (vs. PG_VERSION) to > > pg_ver - Windows > > > > I thought Windows allowed any case, so you could open a file with > > "PG_VERSION" or "pg_version" and it will open any file of any matching > > case. > > The problem is that there exists file PG_VERSION where is the current > version stored (now 6.4) in the directory ./data/base/template1 and when > the bootstrap code wants to create pg_version system table it stops > because the file with the "same" name already exists. That is a good point. Actually template1/pg_version is never used, because it is used for a 'version' command we don't support, and I don't think ever worked. Perhaps I will remove the file. > > > What would you like done with this patch? Should it merged into the > > tree, or just used for people testing things on NT, and later > > merged in > > as you feel more comfortable? You can make a 6.4 final > > patch, perhaps. > > I think we should wait for the final 6.4 version (I hope it will be soon > available) and than make a patch against it and include it also in the > 6.5 development tree. There are some open issues yet. > > I run the regression tests yesterday, the results are here: > =============== running regression queries... ================= > boolean .. ok > char .. ok > name .. ok > varchar .. ok > text .. ok > strings .. ok > int2 .. failed > int4 .. failed > int8 .. failed > oid .. ok > float4 .. ok > float8 .. failed > numerology .. failed > point .. ok > lseg .. ok > box .. ok > path .. ok > polygon .. ok > circle .. ok > geometry .. failed > timespan .. ok > datetime .. failed > reltime .. ok > abstime .. failed > tinterval .. failed > horology .. failed > comments .. ok > create_function_1 .. ok > create_type .. ok > create_table .. ok > create_function_2 .. failed > constraints .. failed > triggers .. failed > copy .. ok > create_misc .. ok > create_aggregate .. ok > create_operator .. ok > create_view .. ok > create_index .. ok > sanity_check .. ok > errors .. ok > select .. ok > select_into .. ok > select_distinct .. ok > select_distinct_on .. ok > select_implicit .. ok > select_having .. ok > subselect .. ok > union .. failed > aggregates .. ok > transactions .. ok > random .. ok > portals .. ok > misc .. failed > arrays .. ok > btree_index .. ok > hash_index .. ok > select_views .. ok > alter_table .. ok > portals_p2 .. ok > setup_ruletest .. ok > run_ruletest .. failed > > now some explanations: > - int2, int4 - there are OK but there is a problem with the error > messages from libc > - int8 - the libc does probably have no support for long long ints in > printf() > - run_ruletest - the difference is only in the name that is selected > from the tables > - many other tests failed due to not having the dynamicly loaded code in > DLLs We have all these problems on most platforms, except for the last one. Good job. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
pgsql-hackers by date: