X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 64775D1B349
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue,  8 Jun 2004 12:13:35 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 15084-01
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue,  8 Jun 2004 15:13:31 +0000 (GMT)
Received: from tao.actarg.com (host25.actarg.com [209.180.91.25])
	by svr1.postgresql.org (Postfix) with ESMTP id 5E742D1B1AC
	for <pgsql-sql@postgresql.org>; Tue,  8 Jun 2004 12:13:30 -0300 (ADT)
Received: from actarg.com (chi.actarg.com [192.168.2.5])
	by tao.actarg.com (8.12.10/8.12.10) with ESMTP id i58FDKiH023186;
	Tue, 8 Jun 2004 09:13:20 -0600
Message-ID: <40C5D790.6090407@actarg.com>
Date: Tue, 08 Jun 2004 09:13:20 -0600
From: Kyle <kyle@actarg.com>
Organization: Action Target Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-sql@postgresql.org, Peter Eisentraut <peter_e@gmx.net>
Subject: Re: Getting FK relationships from information_schema
References: <40C500D8.9060009@actarg.com> <26677.1086673982@sss.pgh.pa.us>
In-Reply-To: <26677.1086673982@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------000201050000010908080008"
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.5 tagged_above=0.0 required=5.0 tests=HTML_MESSAGE,
	HTML_TITLE_EMPTY
X-Spam-Level: 
X-Archive-Number: 200406/59
X-Sequence-Number: 18004

This is a multi-part message in MIME format.
--------------000201050000010908080008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

>Kyle <kyle@actarg.com> 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


--------------000201050000010908080008
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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">&lt;kyle@actarg.com&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 constraint name automatically.&nbsp; 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).&nbsp; 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.<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 to be the _real_ name?&nbsp; Or can we just
make a name consisting of the table name appended to the internal
postgres constraint name.<br>
<br>
I think I like this less than the first idea.<br>
<br>
Kyle<br>
<br>
</body>
</html>

--------------000201050000010908080008--