Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA13157

for <pgman@candle.pha.pa.us>; Thu, 8 Jun 2000 00:31:00 -0400 (EDT)

Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id AAA01089 for <pgman@candle.pha.pa.us>; Thu, 8 Jun 2000 00:17:19 -0400 (EDT)

Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id AAA01089 for <pgman@candle.pha.pa.us>; Thu, 8 Jun 2000 00:17:19 -0400 (EDT)

Received: from hub.org (majordom@localhost [127.0.0.1])

by hub.org (8.10.1/8.10.1) with SMTP id e5846ib99782;

Thu, 8 Jun 2000 00:06:44 -0400 (EDT)

Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10355

for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 01:01:00 -0400 (EDT)

Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id AAA25467 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 00:41:32 -0400 (EDT)

Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id AAA25467 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 00:41:32 -0400 (EDT)

Received: from mcadnote1 (ppm110.noc.fukui.nsk.ne.jp [210.161.188.29] (may be forged))

by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP

id NAA03125; Sat, 10 Jun 2000 13:40:40 +0900

Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10922

for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 01:31:03 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id BAA27265 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 01:16:07 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id BAA27265 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 01:16:07 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])

by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA06206;

Sat, 10 Jun 2000 01:14:37 -0400 (EDT)

Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA25987

for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 09:30:58 -0400 (EDT)

Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id JAA18716 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 09:15:08 -0400 (EDT)

Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id JAA18716 for <pgman@candle.pha.pa.us>; Sat, 10 Jun 2000 09:15:08 -0400 (EDT)

Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])

by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id GAA15799;

Sat, 10 Jun 2000 06:14:28 -0700 (PDT)

Received: from renoir.op.net (root@renoir.op.net [207.29.195.4])

by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA05771

for <pgman@candle.pha.pa.us>; Sun, 11 Jun 2000 12:31:01 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.3 $) with ESMTP id MAA19315 for <pgman@candle.pha.pa.us>; Sun, 11 Jun 2000 12:24:06 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.4 $) with ESMTP id MAA19315 for <pgman@candle.pha.pa.us>; Sun, 11 Jun 2000 12:24:06 -0400 (EDT)

Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])

by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA09503;

Sun, 11 Jun 2000 12:22:42 -0400 (EDT)

************

From pgsql-hackers-owner+M18768=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 03:52:00 2002

Return-path: <pgsql-hackers-owner+M18768=candle.pha.pa.us=pgman@postgresql.org>

Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])

by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1D8pxP21056

for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 03:52:00 -0500 (EST)

Received: (qmail 97959 invoked by alias); 13 Feb 2002 08:51:46 -0000

Received: from unknown (HELO postgresql.org) (64.49.215.8)

by www.postgresql.org with SMTP; 13 Feb 2002 08:51:46 -0000

Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])

by postgresql.org (8.11.3/8.11.4) with SMTP id g1D8mRE97432

for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 03:48:28 -0500 (EST)

(envelope-from Inoue@tpf.co.jp)

Received: (qmail 26891 invoked from network); 13 Feb 2002 08:48:27 -0000

Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)

by sd2.tpf-fw-c.co.jp with SMTP; 13 Feb 2002 08:48:27 -0000

Received: from tpf.co.jp (3dgateway1 [126.0.1.60])

by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id RAA01019;

Wed, 13 Feb 2002 17:48:20 +0900 (JST)

Message-ID: <3C6A2861.6E71A124@tpf.co.jp>

Date: Wed, 13 Feb 2002 17:48:33 +0900

From: Hiroshi Inoue <Inoue@tpf.co.jp>

X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)

X-Accept-Language: ja

MIME-Version: 1.0

To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>

cc: Tom Lane <tgl@sss.pgh.pa.us>,

Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>,

pgsql-hackers@postgresql.org

Subject: Re: [HACKERS] alter table drop column status

References: <GNELIHDDFBOCMGBFGEFOMEFPCBAA.chriskl@familyhealth.com.au>

Content-Type: text/plain; charset=iso-2022-jp

Content-Transfer-Encoding: 7bit

Precedence: bulk

Sender: pgsql-hackers-owner@postgresql.org

Status: OR

Christopher Kings-Lynne wrote:

>

> > No there was an unapplied hack which uses logical/physical

> > attribute numbers. I have synchronized it with cvs for a

> > year or so but stop it now. Though it had some flaws It

> > solved the following TODOs.

> >

> > * Add ALTER TABLE DROP COLUMN feature

> > * ALTER TABLE ADD COLUMN to inherited table put column in wrong place

> > * Prevent column dropping if column is used by foreign key

>

> This seems fantastic - why can't this be committed? Surely if it's

> committed then the flaws will fairly quickly be ironed out? Even if it has

> flaws, then if we say 'this function is not yet stable' at least people can

> start testing it and reporting the problems?

>

> > I gave up to apply the hack mainly because it may introduce

> > the maintenance headache.

>

> Is it a maintenance headache just for you to keep it up to date, or how

> would it be a maintenance headache if it were committed?

Probably(oops I don't remember well now sorry) the main

reason why I didn't insist to apply the patch was that

it wasn't so clean as I had expected.

My trial implementation uses logical(for clients) and

physical (for backend internal) attribute numbers but

there were many places where I wasn't able to judge which

to use immediately. I'm pretty suspicious if a developer

could be careful about the choise when he is implementing

an irrevant feature. (Un)fortunately the numbers have

the same values mostly and he could hardly notice the

mistake even if he chose the wrong attribute numbers.

I'm not sure if I myself chose the right attribute numbers

everywhere in my implementation.

In addtion (probably) there were some pretty essential

flaws. I intended to manage the backend internal

object references without the logical attribute

numbers but I found it difficult in some cases

(probably the handling of virtual(not existent

in any real table) tuples).

Sorry it was more than 1 year ago when I implemented

it and I can't remember well what I'd thougth then.

Though I'd kept my local branch up to date for

about a year, it's about half a year since I touched

the stuff last.

regards,

Hiroshi Inoue

---------------------------(end of broadcast)---------------------------

TIP 2: you can get off all lists at once with the unregister command

(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)