Add Postgresql support
pillarsdotnet - October 2, 2007 - 06:50
| Project: | Path Redirect |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
The attached patch adds Postgresql support.
--- orig/path_redirect/path_redirect.install 2007-03-16 13:40:46.000000000 -0400
+++ patched/path_redirect/path_redirect.install 2007-10-02 02:28:42.000000000 -0400
@@ -16,6 +16,16 @@
UNIQUE KEY rid (rid)
) /*!40100 DEFAULT CHARACTER SET utf8 */;");
break;
+ case 'pgsql':
+ db_query("CREATE TABLE {path_redirect} (
+ rid SERIAL UNIQUE,
+ path varchar(255) NOT NULL PRIMARY KEY,
+ redirect varchar(255) NOT NULL,
+ query varchar(50) NOT NULL,
+ fragment varchar(50) NOT NULL,
+ type varchar(40) NOT NULL
+ );");
+ break;
}
drupal_set_message(t('Database tables for the Path Redirect module have been installed.'));
}
--- orig/path_redirect/path_redirect.module 2007-05-01 21:33:42.000000000 -0400
+++ patched/path_redirect/path_redirect.module 2007-10-02 02:37:51.000000000 -0400
@@ -26,9 +26,9 @@
// check through the redirects
// see if this page is one of those
$path = db_escape_string($_GET['q']);
- $r = db_fetch_object(db_query('SELECT redirect, query, fragment, type FROM {path_redirect} WHERE path = "%s"', $path));
+ $r = db_fetch_object(db_query("SELECT redirect, query, fragment, type FROM {path_redirect} WHERE path = '%s'", $path));
if ($r) {
- drupal_goto($r->redirect, ($r->query ? $r->query: NULL), ($r->fragment ? $r->fragment : NULL), $r->type);
+ drupal_goto(($r->redirect=='/'?'':$r->redirect), ($r->query ? $r->query: NULL), ($r->fragment ? $r->fragment : NULL), $r->type);
}
}
@@ -280,10 +280,10 @@
function path_redirect_save($edit) {
if (!$edit['rid']) {
- $edit['rid'] = db_next_id('{path_redirect}');
+ $edit['rid'] = db_next_id('{path_redirect_rid}');
}
path_redirect_delete_do($edit['rid']);
- return db_query('INSERT INTO {path_redirect} (rid, path, redirect, query, fragment, type) VALUES (%d, "%s", "%s", "%s", "%s", "%s")', $edit['rid'], $edit['path'], $edit['redirect'], $edit['query'], $edit['fragment'], $edit['type']);
+ return db_query("INSERT INTO {path_redirect} (rid, path, redirect, query, fragment, type) VALUES (%d, '%s', '%s', '%s', '%s', '%s')", $edit['rid'], $edit['path'], $edit['redirect'], $edit['query'], $edit['fragment'], $edit['type']);
}
function path_redirect_delete_do($rid) {| Attachment | Size |
|---|---|
| path_redirect.postgresl.patch | 2.22 KB |
#1
drupal_goto(($r->redirect=='/'?'':$r->redirect)...It looks like you might have included the "redirect to front" patch I whipped up. If so, you may want to reroll this patch without it, and also consider the substantial improvement contributed by John Morahan.
#2
Right you are. Here's the patch without the "to-front" modification.
#3
It's probably worth noting that this patch also changes the sequence name from
{path_redirect}to{path_redirect_rid}which is probably a good thing. However, we'll need anotherpath_redirect_update_nthat changes the name stored in the{sequences}table for MySQL.Thank you for the patch!
#4
Committed. Please download 5.x-1.1-beta1 to test.
#5
This won't quite work with Postgres. Using the
serialtype forridwill create the sequence{path_redirect}_rid_seqand we'll need to calldb_next_id("{path_redirect}_rid")instead. Here's a patch which I have not yet tested which should update MySQL installs to use the correct sequence and will also deal with dropping the sequence when the module is uninstalled.#6
Oops... changing status.
#7
Part of this patch has already been committed. It looks like the #5 patch is against the latest commit. Correct?
And Postgres doesn't use the sequences table? I guess that's only the beginning of what I don't know about Postrgres. :-)
Patch looks good. I can't test because... well... you know.
#8
This patch removes the
DROP SEQUENCE, since apparently the sequence is dropped automatically when you drop the table if you use theserialtype. Handy!Both of these patches were against the latest release (5.x-1.1-beta1), rather than the latest commit, assuming those are different. I can download the latest commit and reroll if necessary.
#9
Yo HorsePunchKid, I tried out your patch and it works great! Totally solves that problem I had with not being able to try out the niftyness of path_redirect because of some fugly errors with the postgresql code like these:
pg_query() [<a href='function.pg-query'>function.pg-query</a>]: Query failed: ERROR: duplicate key violates unique constraint "path_redirect_rid_key" in /var/www/aigeanta.net/includes/database.pgsql.inc on line 125.query: SELECT nextval('path_redirect_seq') in /var/www/aigeanta.net/includes/database.pgsql.inc on line 144.pg_query() [<a href='function.pg-query'>function.pg-query</a>]: Query failed: ERROR: relation "path_redirect_seq" does not exist in /var/www/aigeanta.net/includes/database.pgsql.inc on line 125.Before, I was able to add one redirect but it errored out the next couple times. After un-installing path_redirect, applying the patch, and making some new redirects, they were successfully added to the table and no errors made the logs. Awesome!
#10
Thanks for the feedback! I have tested this on fresh and existing installs of MySQL and on a fresh install of Postgres, and all appears to be working fine. I rolled the code into the same update as for this issue; hopefully that was the right choice.
#11
Automatically closed -- issue fixed for two weeks with no activity.