Tom Lane wrote: <blockquote cite="mid26677.1086673982@sss.pgh.pa.us" type="cite"><pre wrap="">Kyle <a
class="moz-txt-link-rfc2396E"href="mailto:kyle@actarg.com"><kyle@actarg.com></a> writes: </pre><blockquote
type="cite"><prewrap="">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. </pre></blockquote><pre wrap="">
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. </pre></blockquote> I think this is only an issue when the user relies on postgres to choose a
constraintname automatically. Seems like a reasonable approach would be to have postgres choose a name for the
constraintthat happens to be unique in the schema (like tablename_fkey_$1). Then if the user wants to make named
constraintsthat all have the same name, he can (and information_schema will be less useful) or he can rely on the
automaticallygenerated names to be a bit more descriptive in information_schema.<br /><blockquote
cite="mid26677.1086673982@sss.pgh.pa.us"type="cite"><pre wrap="">Can we get away with adding
implementation-specific columns to information_schema tables?
If not, what other alternatives are there?
</pre></blockquote> Another possible approach: Does the constraint name showing up in information_schema really have
tobe the _real_ name? Or can we just make a name consisting of the table name appended to the internal postgres
constraintname.<br /><br /> I think I like this less than the first idea.<br /><br /> Kyle<br /><br />