During my investigation of PostgreSQL installation incompatibility in content.install, I discovered that the various integer types mentioned in the code in content_admin.inc are basically not supported.
This is what I'm talking about: http://drupal.org/node/74535
In other words, CCK seems to turn everything into integers and not base the database column data type on the minimum and maximum values entered for a number field.
If I enter in a 1 to 255, it should make the value a smallint. If it's 2 billion or less, it should be an integer, and if over 2 billion (whatever the hard limit is) it should be a bigint in PostgreSQL. I wrote in code in the above situation to make it turn unsigned int's into bigint's, but the system doesn't seem to use those min-max values at all when deciding what kind of integer to create in the table.
Let me know if my analysis is off the mark, and how to use my patched version (noted above) to properly generate bigint's.
Comments
Comment #1
wim leersConfirmed in MySQL as well. See this: http://drupal.org/node/198515#comment-652181.
Comment #2
wim leersFor some reason, when I pass the very simple number
1640, it gets saved as1639. And it's NOT caused by CCK. It's caused somewhere in the DB layer… Will update this post when I've tracked it down.EDIT: please ignore this comment, it was due to a PHP type casting flaw: http://drupalbin.com/958.
Comment #3
wim leersThe D5 version of this module won't get updated.
I want this out of my list of issues.