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