We have some problems installing NextBBS (version 0.4.6) on a system with a postgres DB.

The virtual server that should 'carry' the forum offers the following possibilities:
- PHP Version 4.3.10
- Postgres Version 8.0
- Operating system is Linux

We created a database-user with the rights to create databases.
After that we created a database.

During the installation process after having typed in the database-connection-information, the wizard tries to connect to the database and assures, that tables can be created.
We experience the first problem here. The connection to the database passes successfully, the rest is marked as failed.
The problem seems to be here (wizard.php, line 895):

$qry = "CREATE TABLE nwiztestdropme(afield integer(10))";

cause with:

$qry = "CREATE TABLE nwiztestdropme(afield integer)";

the test would pass successfully.

There seems to be a lot of mySQL specific code in there. Is NextBBS really compatible to a postgres database without major manipulation to the source code?

Or did we just forget something before trying to install NextBBS.

---

Saavik,

My bad: I wrote or rewrote all the database code and, lately, I've only been doing my testing using MySQL.
If you can wait a few more days, I am going to "re-standardize" the code that doesn't work with PGSQL.

---

That forum here looks good... so it is worth to wait.

(We already tried to rewrite some of it. But I don't know yet if it works.)

Last edit by Saavik on Jan 31, 2007, 8:53 am

---

Actually, I am wondering if you would let me work on your server?
Every postgres install (2) we've tested so far were hand-crafted and maybe not the best setup ever.

---

In between I finished an importable safedump.sql, but there is code to change in many .php files, too.
Needed changes
- all int(x) were converted to int
    (all int datatypes are 4 Byte Integer, often used as int4 or integer. They differ when returning results, int(3) in mysql
    returns 1 as 001 and int(5) as 00001. This is mysql-only. Do not get confused by number(X) or varchar(X))
- tinyint is not defined in sql or postgres, replacing it by smallint
- auto increment is not known by postgres, replaced data type by serial or bigserial. may be propriatary postgres
- blobs are not known by postgres, replaced it with bytea (byte array), may be propriatary postgres
- user is a reserved keyword of sql, it must not be used as table column. (for importing it I changed it, but it has to be renamed everywhere)
- `table` is propiatary mysql, just remove the `.
- "string" is illegal, use 'string' instead
- # is no sql comment, replace it by --
- password(string) is a mysql function for internal use only, it should not be used anywhere else. (Mysql 5.1 documentation) I replaced it by md5(string),
   but this should be changed into using of salted hash, like md5(md5(string) || salt) where || means string concatenation, not OR.
- create new indixes, key is no postgres-keyword. (this step may be leaved out for testing. Just remove the keys.)
- drop if exist is not known by postgres, drop is allowed only, if table exists. I commented them out.
- timestamp: there is a timespace function within postgres, there is no need to use unix like timestamp.

There are some perl scripts to port sql from mysql to postgres, but I didn't used them. I hope I forgot not too much.
Testing on Saaviks and mine server should be possible, but this is just a standard pgsql installation, too, and not the latest version.

At the moment, I have some problems with the filter methods within main.php. As soon I understand what they should do and what they do here, I continue working on the conversation.

Last edit by Kazzenkatt on Feb 6, 2007, 9:49 am

---

There are many other issues, array $visibleareas has no entries, so $inareas = '\'' . implode('\',\'', array_keys($visibleareas)) . '\''; has the value '\'\'' which is no integer.

- LIMIT offset,length has to be written as LIMIT length OFFSET offset

---

I see. The visibleareas issue should persist until you create a forum. I should clean up the code so that it handles that special case.
Yes, limit is my nemesis: Oracle, hsqldb for instance use completely different syntaxes (different reserved word actually)

---