phpGroupWare - Bugs: bug #3479, an existing field being retyped to...
You are not allowed to post comments on this tracker with your current authentication level.
bug #3479: an existing field being retyped to an auto field should go through this process
Submitter: | Johnson <jecinc> | ||
Submitted: | Tue 06 May 2003 03:43:36 AM UTC | ||
Category: | API - phpGroupware API | Item Group: | None |
Severity: | 6 - Security | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Component Version: | None | Operating System: | None |
Reproducibility: | None | Planned Release: | None |
Fixed Release: |
Mon 07 Jun 2004 01:58:54 PM UTC, comment #2: |
Johnson <jecinc> |
Tue 06 May 2003 04:59:02 PM UTC, comment #1: Again a useful feature request ;-)
|
Invalid User ID <#2883> |
Tue 06 May 2003 03:43:36 AM UTC, original submission:
This is an example for postgresql to get the maximum value for a field and another example to set the sequance value to that value plus one
|
Johnson <jecinc> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2004-06-07 | jecinc | Category | eTemplates | API - phpGroupware API | |
Severity | 3 - Normal | 6 - Security | |||
Assigned to | Caeies | None | |||
2004-06-06 | skwashd | Assigned to | None | Caeies | |
2004-01-20 | powerstat | Assigned to | #2883 | None | |
2003-05-06 | #2883 | Assigned to | None | None |
Powered by Savane 3.13-f8d8.
Corresponding source code
It seems this is a pgsql api issue not an eT dbtools issue.
When a field's type, name, or length is changed, on a postgresl system, the sequence and index values are dropped.
This is because it creates a new table, copies the original tables content, then deletes the original table and renames the new table (with the new schema)
The index and it's sequence needs to be recreated
Perhaps just using a dummy column instead of a dummy table would work .. but it would prevent the index field name or type from being changed.