This project is archived and is in readonly mode.
Postgres SchemaDumper does not preserve composite index column order
Reported by Kevin Menard | April 24th, 2009 @ 10:15 PM | in 2.x
The schema dumper used by the PostgreSQL adapter does not preserve column order for composite keys. It issues a query against internal Postgres tables and does no further sorting. While this leaves it up to the DB to decide, I've found that Postgres 8.3 on MacOS X seems to return in attribute number ascending order. So, the problem wouldn't appear if every subsequent column in the index appeared later than all previous ones in the table definition. If the columns used in the index are not in the same sequential ordering as the table definition, the dumped "add_index" line is wrong.
While looking into this code, too, I noticed an artificial upper limit on the number of columns in composite indices. As of 8.3, Postgres allows up to 32 columns. The PostgreSQL adapter, however, caps this at 10.
Comments and changes to this ticket
-
Kevin Menard April 24th, 2009 @ 10:31 PM
Nevermind. This is a duplicate of #2515 and has already been fixed. I came across the problem before that ticket was opened and didn't get to really investigate until just now.
-
CancelProfileIsBroken April 24th, 2009 @ 10:43 PM
- State changed from new to duplicate
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>