On Tue, Mar 14, 2006 at 11:11:29PM -0800, Stephan Szabo wrote: | When we're allowing other order access, immediately reorder the | constraint information to match the primary key order.
Let me try to parrot. In PostgreSQL, the pairing information between the foreign-key and unique-key constraint is available; even though it isn't represented in the information_schema. Hence, this option re-orders the foreign-key columns to match the corresponding canidate key constraint (unique _or_ foreign key). If so, I like it. | This helps out | with IS since the loaded constraint should display properly, but | theoretically could change the visual representation after load for people | who don't care about this option. I doubt that the actual ordering of the columns in the foreign key constraint matters to people; so I don't see a downside with this option other than the perhaps unexpected difference. | Change the representation unconditionally on dump. Basically reorder the | constraint at dump time to always generate a dump in SQL03 order. This has | the same downside as the above except only after another dump/restore. You could do both? | Change the representation on dump only if the flag is set (probably | exporting this as an option to pg_dump as well). This could be a little | more difficult to use, but pretty much causes the user to drive the | choice. Hmm. I just cannot think of a reason why someone would even care that the columns in their foreign-key constraint create get re-orderd as long as the behavior is the same. Best, Clark ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
