Hallo,

  \d information_schema.referential_constraints
   View "information_schema.referential_constraints"
   ...
    FROM pg_namespace ncon
    JOIN pg_constraint con ON ncon.oid = con.connamespace
    JOIN pg_class c ON con.conrelid = c.oid

Well, for the sake of argument, how would you propose to change it?

For the sake of argument:

For the information_schema to be useful, expected keys & foreign keys must work properly so that the constraints can be joined meaningfully (otherwise, what is the point?). So any change would have to be be consistent over all definitions.

The standard expects the triplet <catalog,schema,constraint> to be unique, but in Pg, <catalog,schema,table,constraint> is unique (I think). Too late to change that, obviously. So that let building a unique constraint name just for the information_schema, which is fine with me.

(1) use the OID as the "constraint name" everywhere, it would work, it would not look so good for display, but it is simple and fast.

(2) otherwise something built on top of <table,constraint>. To be on the safe side, I would build a string (sql_identifier?) with something like:

    quote_ident(<table name>) || '.' || quote_ident(<constraint name>)

And the display would be reasonnable, like : "TableName"."$1" instead of a big bunch of $1.

The affected information_schema views would be, as far as I can see:
 - check_constraint_routine_usage
 - check_constraints
 - constraint_column_usage
 - constraint_table_usage
 - domain_constraints
 - key_column_usage
 - referential_constraints
 - table_constraints
With one or two affected columns each.

Note that there may be the same issue with 'triggers' which are also identified by a <catalog,schema,trigger> triplet. Maybe others.

I can send a patch on the information_schema definition in the coming days if someone feel that this may deserve a "test". Otherwise, ISTM that it is a "bug" to be recorded somewhere.

Have a nice day,

--
Fabien.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to