RE: [HACKERS] NT port of PGSQL - success

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

> 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

Dan