Tom Lane wrote:
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.  
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.
Can we get away with adding
implementation-specific columns to information_schema tables?
If not, what other alternatives are there?

  
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.

I think I like this less than the first idea.

Kyle

Reply via email to