Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Date
Msg-id 493FD440.5020206@dunslane.net
Whole thread Raw
In response to Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers

Merlin Moncure wrote:
> On Wed, Dec 10, 2008 at 9:05 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>   
>> Merlin Moncure escribió:
>>     
>>>>>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>>>>> OK, so what should the TODO item be?
>>>>>           
>>> On Wed, Dec 10, 2008 at 7:44 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>       
>>>> Allow ALTER TYPE to add, rename, change the type of, and drop columns?
>>>>         
>>> That's probably the consensus view.  Personally, I think creating
>>> composite types through 'create type as' was a mistake...we probably
>>> should have gone through create table instead with some special syntax
>>> for storage-less tables aka composite types.
>>>       
>> I disagree that CREATE TABLE should be (or should have been) used to
>> create types.  Someday we might need to expand the work we do for that
>> case in a different direction than tables, and we would be stuck.
>>     
>
> But, tables _are_ types, particularly in relational parlance.  In
> fact, postgresql's older, more relational terms (tuples and such) are
> coming from that perspective, although I admit that's mostly
> irrelevant now.  I think we are more stuck now, having to re-implement
> many things alter table does in 'alter type (as)???'.  It's a mess.
> What if we want to add check constraints to composite types?
>
>   
>> Also, for tables we create files, we generate statistics, we compute
>> relfrozenxid, we call vacuum on, and so on and so forth.  We do none of
>> these things on types.
>>     
>
> Those things are what come with 'storage' so if you are defining a
> type with no storage mechanism you could possibly skip those things.
>
>   
>> In fact, types are not in pg_class at all.
>>     
>
> incorrect!!  composite types are in pg_class (relkind='c').  That
> actually knida confirms what I'm saying, composite types were added in
> a confusing overlay over the 'create type' command, which is something
> completely different.  create type means two completely different
> things depending on a minor grammar change...gah! :-)
>
> I still stand by by statement...create table should have allowed you
> to create a composite type as we do it with create type as today...and
> (perhaps) storage (relfrozenxid etc.) could be added or removed with
> alter table.
>
>
>   

This whole debate seems moot. We're not going to remove composite types 
created with CREATE TYPE, so the rest is irrelevant. We don't have the 
luxury of revisiting such decisions made many years ago, whether or not 
you think they were good.

cheers

andrew


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Next
From: Alvaro Herrera
Date:
Subject: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine