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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Дата
Msg-id 493FD440.5020206@dunslane.net
обсуждение исходный текст
Ответ на Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine  ("Merlin Moncure" <mmoncure@gmail.com>)
Ответы Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine  (Andrew Chernow <ac@esilo.com>)
Список 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 по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine