X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 01EC8D1D067 for ; Fri, 23 Apr 2004 05:16:39 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 12050-08 for ; Fri, 23 Apr 2004 05:16:38 -0300 (ADT) Received: from servata.com (unknown [64.70.4.194]) by svr1.postgresql.org (Postfix) with ESMTP id EC74AD1CCDC for ; Fri, 23 Apr 2004 05:16:36 -0300 (ADT) Received: from [66.27.58.226] (helo=rrcs-west-66-27-58-226.biz.rr.com) by servata.com with asmtp (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.30) id 1BGw1f-0000nP-0R; Fri, 23 Apr 2004 01:27:11 -0700 Subject: Re: [HACKERS] What can we learn from MySQL? From: Jeff Davis To: Christopher Kings-Lynne Cc: PostgreSQL advocacy In-Reply-To: <4088B944.1050007@familyhealth.com.au> References: <200404230409.i3N49jC02890@candle.pha.pa.us> <4088B944.1050007@familyhealth.com.au> Content-Type: text/plain Message-Id: <1082708197.32307.1136.camel@jeff> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 23 Apr 2004 01:16:38 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.1 tagged_above=0.0 required=5.0 tests=RCVD_IN_SORBS X-Spam-Level: X-Archive-Number: 200404/136 X-Sequence-Number: 4108 > I have already told Bruce at length about the single most common > complaint in the phpPgAdmin lists and in the IRC channel: the inability > to change column types. I think we should listen to the punters on that > one. > Maybe a simple and less dangerous option would be to add a column of the new type, rename the old column and hide it, and select from the old column and cast it to the new column? Is that a feasible implementation? If I really need to change a column, that's what I'd do. It's certainly less dangerous than MySQL. I remember a horror story watching my column silently cast itself to a bunch of blank values in MySQL. In postgres you'd just be able to undo it or fix the problem since the data is still there. I also understand that MySQL has to copy the entire table or something insane like that, so we could use the opportunity to brag about how much more efficient we are for large tables. Regards, Jeff Davis