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

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "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-08 14:17:08
Message-ID: b42b73150812080617k567597eftfee9bd4d5c8fac94@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 8, 2008 at 8:01 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Merlin Moncure wrote:
>> Well, new features that have a perfectly acceptable and usable
>> workaround typically have a fairly low priority of fixing :-)
>>
>> Since tables are basically types, I'm not sure what the difference is
>> between tables and composite types (meaning, why do we have the
>> composite type syntax at all?) I'm not sure if this came up during
>> the design discussion or not.
>
> Your "workaround" involves have a redundant table that you don't ever intend
> to populate.

Redundant how? Since tables and types exist in the same namespace
(can't have table and type in the same schema with the same name), a
table is just a type with storage. If that's a big deal, remove the
insert priv...

I like to keep the table based types I use in a special schema, like
'types' anyways.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-12-08 14:30:58 Re: Multiplexing SUGUSR1
Previous Message Simon Riggs 2008-12-08 14:04:51 Re: Sync Rep: First Thoughts on Code