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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, dmitry(at)koterov(dot)ru, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Date: 2008-12-10 14:37:52
Message-ID: 493FD440.5020206@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure wrote:
> On Wed, Dec 10, 2008 at 9:05 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>
>> Merlin Moncure escribió:
>>
>>>>> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
>>>>> OK, so what should the TODO item be?
>>>>>
>>> On Wed, Dec 10, 2008 at 7:44 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-12-10 14:39:53 Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Previous Message Robert Haas 2008-12-10 14:24:35 Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine