pathauto installation undefined function db_change_column

This is interesting. I've done several fresh installs and never had this problem. Can you confirm that the update.php file exists on your server? Perhaps you are just the first person on PostgreSQL who installed the 5.x-2.0 version?

That code was only added so that the module would work with custom node types that have reaaaaally long names. So...I've removed this temporarily from the -dev branch so that at least it will work for the majority of users.

According to http://www.postgresql.org/docs/7.4/interactive/sql-altertable.html

We need to do something like this to have the same effect on mysql when running under pgsql:

BEGIN;
LOCK TABLE variable;
ALTER TABLE variable ADD COLUMN new_name varchar(128) NOT NULL DEFAULT '';
UPDATE variable SET new_name = name;
ALTER TABLE variable DROP COLUMN name;
ALTER TABLE variable RENAME new_name TO name;
COMMIT;

Perhaps you could test that on a test system? If so I'll add a note about how to do that to the README.txt or INSTALL.TXT for pgsql users

I just got the same error. Instead of the db_change_column call, I just changed it to:

db_query("ALTER TABLE {variable} ALTER name TYPE varchar(128)");

This worked fine against Postgres 8.2.4. No need to reiterate the NOT NULL and DEFAULT clauses, since they're already there. I don't have a 7.4 to test on, but the docs make it look like this should work there, too.

I don't have postgresql to test against, so if one of you could roll and test a patch that would be great.

Same thing in patch form. I don't understand the error, but this fixes it.

HorsePunchKid - thanks. Did you test on 7.3/7.4? That reference page you pointed to doesn't show the use of this syntax as far as I can tell.

@lylep - could you test this latest patch? I generally like to have at least one extra tester besides the person who creates a patch (regardless of whether it's me or someone else...).

After reviewing this patch more closely it seems wrong. The update_2 should work AFAIK - the problem is in pathauto_install, right?

@lylep - that function is only available in update.php which is only available when updating the schema - not installing it. Along those same lines - if you tested this on a system where Pathauto1.2 was installed then that doesn't test this problem because the code in question is never run.

For drupal 6 I believe the point is moot - the new schema system makes creation/maintenance of these tables much simpler.

So, we either have to copy the logic of db_change_column into pathauto.install OR we just ignore PostgreSQL7.x users. Thoughts?

The reason I didn't like the idea of the longer command was that I was concerned that the Drupal user might not have the permissions to run all those commands. Then I read INSTALL.pgsql.txt which doesn't have _any_ mention of grants so maybe we don't need to worry about that :) Besides, the db_change_column does them all anyway...so maybe I'll just do that.

I'll try to make a patch soon so you can test it on your new install, lylep.

I think that the patch utility got confused when I applied it. Horsepunchkid's fix was in the right place, but not against the latest tip of the branch so my patch utility applied it wrong. Whoops.

Re-rolled to fix this and committed to DRUPAL-5--2

If someone can write the patch that will get it working with older versions of PostgreSQL that would be awesome. I've added this to the PgSQL queue of issues to review.

this was just doing something that is done in the 6.x update anyway so it should not be applied to HEAD...

I'm a little busy right now, but I will provide a patch for pathauto 5.x-2.x tomorrow. Besides the queries listed above, a new constraint needs to be created to make the new name column the primary key once again, since the original constraint is lost upon dropping the old one.

@stormsweeper - please mark as "code needs review" when you have attached the patch.

Otherwise, this is closed. Thanks.