database schema out of sync with code

Yeah, it seems like the i18n.install script isn't working. I downloaded a fresh copy of Drupal 4.7 and i18n, and when I activated i18n, it didn't seem to modify the database. When I tried to create a new Page node, the following error confirmed this:

warning: pg_query(): Query failed: ERROR: column v.language does not exist in database.pgsql.inc on line 84.

Whatever you do, don't use the old i18n.pgsql that's still bundled with this module, however, because it contains the old i18n schema.

I should mention that I'm using PostgreSQL 8.x, and I realize that Drupal leans toward MySQL, so the install script will likely do something different in MySQL.

My mistake; I did another update and it looks like the taxonomy tables have been removed from i18n.pgsql, so it's up-to-date with the current cvs. I'm going to try it again, first installing i18n.pgsql and then the module, to see if i18n.install works in that order.

I've updated again the install file.

However, I'm not using PostgreSQL at all, so I appreciate any feedback and/or help with that update scripts for pgsql

Then I can set it to fixed?

Fixed, thanks again.

Sorry if this isn't the right place for this question, but I see that i18n_node still exists while i18n_taxonomy has been deprecated for 'language' and 'trid' columns in the term_data table. Will nodes and their translations be eventually correlated in this way as well?

> i18n_node still exists while i18n_taxonomy has been deprecated for 'language' and 'trid' columns in the term_data table. Will nodes and their translations be eventually correlated in this way as well?

I cannot tell you, it will depend on the evolution of Drupal I guess.

It doesn't really make too much difference whether they're on their own table or in a different one. But for this version of Drupal -and without patching the core- it had some advantages having it like that, like saving database queries.

Okay, thanks.