Re: constraints and sql92 information_schema compliance

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