Re: DROP COLUMN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN
Date
Msg-id 28536.1026792551@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Responses Re: DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> I agree that a wrapper function is probably an appropriate solution,
>> but only some of the calls of SearchSysCache should use it.

> What like add another parameter to SearchSysCache*?

Definitely *not*; I don't want to kluge up every call to SearchSysCache
with a feature that's only relevant to a small number of them.

> Another question: How do I fill out the ObjectAddress when trying to drop
> related objects?

A column would be classId = RelOid_pg_class, objectId = OID of relation,
objectSubId = column's attnum.

BTW, it occurred to me recently that most of the column-specific
AlterTable operations will happily try to alter system columns (eg,
OID).  In most cases this makes no sense and should be forbidden.
It definitely makes no sense for DROP COLUMN...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] CLUSTER not lose indexes
Next
From: Joe Conway
Date:
Subject: Re: bit type external representation