PostgreSQL issue with int length
AlexisWilke - April 17, 2009 - 03:30
| Project: | Bitcache |
| Version: | 6.x-1.x-dev |
| Component: | Installation |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Arto |
| Status: | patch (to be ported) |
| Issue tags: | PostgreSQL |
Jump to:
Description
Hi there,
When I try to install your module, it fails with PostgreSQL because you have a length parameter with integers.
The fact is you cannot have a length parameter. Also you had a length set to 4 for a 'tiny' type which I think is contradictory (which one is correct? 'tiny' or 4?)
Removing the length parameters fixes the problem. You had a valid size in each one of those so the size of the integer is correct.
Thank you.
Alexis Wilke
| Attachment | Size |
|---|---|
| bitcache-6.x-1.0-int-length.patch | 1.99 KB |
#1
Btw,
I had another comment to make. If the creation of the table fails, then the uninstall fails very badly because you get a $class name on line 680 and make use of that class name as is even though in my case that name was empty (null). That code sounds really scary if you ask me!
<?phpfunction bitcache_get_repository($name = 'bitcache') {
...
$class = bitcache_get_adapter_class(!empty($repo['adapter']) ? $repo['adapter'] : 'file');
// I suggest testing that $class is defined
if($class) {
return new $class($repo);
}
// should function return some default here?
}
?>
Thank you.
Alexis Wilke
#2
Alexis, the length parameter is quite valid with MySQL. TINYINT is the storage type and the length is merely the display length (which doesn't affect the storage type).
It's a bit unexpected that this causes problems on PostgreSQL. I will look into it (and probably remove the length parameter as advised) in time for the next release (due imminently).
#3
Arto,
Maybe Drupal should not include the size parameter in PostgreSQL for numbers (i.e. ignore it totally).
It is not SQL92 compliant. MySQL is not compliant for a lot of things. PostgreSQL is much more compliant.
Thank you.
Alexis
#4
Yes, I agree - the best thing would be if Drupal didn't output incorrect SQL for PostgreSQL.
But given that core can't be modified, I suppose that I have no choice but to drop the lengths in order to make this work for PostgreSQL. It's too bad, really, as it is a useful feature for MySQL.