Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id B19759FA463
	for <pgsql-sql-postgresql.org@postgresql.org>;
	Thu, 12 Oct 2006 02:26:17 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 54932-02 for <pgsql-sql-postgresql.org@postgresql.org>;
	Thu, 12 Oct 2006 02:26:15 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 56BC79FA318
	for <pgsql-sql@postgresql.org>; Thu, 12 Oct 2006 02:26:14 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k9C5PmDE002324;
	Thu, 12 Oct 2006 01:25:48 -0400 (EDT)
To: Bryce Nesbitt <bryce1@obviously.com>
cc: pgsql-sql@postgresql.org
Subject: Re: Is this a bug? Deleting a column deletes the constraint. 
In-reply-to: <452DCE97.2090706@obviously.com> 
References: <452DCE97.2090706@obviously.com>
Comments: In-reply-to Bryce Nesbitt <bryce1@obviously.com>
	message dated "Wed, 11 Oct 2006 22:11:51 -0700"
Date: Thu, 12 Oct 2006 01:25:48 -0400
Message-ID: <2323.1160630748@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.09 tagged_above=0 required=5 tests=AWL,
	SPF_HELO_PASS, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200610/115
X-Sequence-Number: 26504

Bryce Nesbitt <bryce1@obviously.com> writes:
> I got bit by this to be sure, but is it a bug?  I guess I'd hoped for a
> warning at the critical step (see "poof" below):

> create table tester (one int, two int, three int);
> alter table only tester add constraint no_dupes unique (one, two, three);
> ...
> alter table tester drop column old_three;
> \d tester;                                    -- poof, the constraint is
> gone with no warning

I don't think the renaming is relevant: you get the same with

regression=# create table tester (one int, two int, three int, unique (one,two,three));
NOTICE:  CREATE TABLE / UNIQUE will create implicit index "tester_one_key" for table "tester"
CREATE TABLE
regression=# alter table tester drop column three;
ALTER TABLE
regression=# \d tester
    Table "public.tester"
 Column |  Type   | Modifiers 
--------+---------+-----------
 one    | integer | 
 two    | integer | 

regression=# 

It does seem like this is wrong, in view of SQL92's statement about
ALTER TABLE DROP COLUMN:

         4) If RESTRICT is specified, then C shall not be referenced in
            the <query expression> of any view descriptor or in the <search
            condition> of any constraint descriptor other than a table con-
            straint descriptor that contains references to no other column
            and that is included in the table descriptor of T.

IOW we should only allow unique constraints to be auto-dropped if
they reference just the one single column.  Ick.

			regards, tom lane