Tom Lane wrote:
I think this is only an issue when the user relies on postgres to choose a constraint name automatically. Seems like a reasonable approach would be to have postgres choose a name for the constraint that happens to be unique in the schema (like tablename_fkey_$1). Then if the user wants to make named constraints that all have the same name, he can (and information_schema will be less useful) or he can rely on the automatically generated names to be a bit more descriptive in information_schema.Kyle <[EMAIL PROTECTED]> writes:The problem is, the constraint names ($1, $2, etc.) are not unique so I don't know how to join the third query into the fourth.Hmm, this is messy :-(. The SQL spec requires constraint names to be unique within a schema. Postgres doesn't require them to be unique even within a table. Another possible approach: Does the constraint name showing up in information_schema really have to be the _real_ name? Or can we just make a name consisting of the table name appended to the internal postgres constraint name.Can we get away with adding implementation-specific columns to information_schema tables? If not, what other alternatives are there? I think I like this less than the first idea. Kyle |