Re: Overhaul of type attributes modification

On 9 July 2011 13:25, Guillaume Lelarge <guillaume@lelarge.info> wrote:
> On Sat, 2011-07-09 at 13:14 +0100, Thom Brown wrote:
>> > The major issue is why we use the "drop all, add all" method.  Let's say
>> > I have a composite type declared like this:
>> >
>> > CREATE TYPE s1.ty2 AS
>> >   (c1 integer,
>> >    c2 integer,
>> >    c3 text,
>> >    c4 integer);
>> >
>> > If I change c3's type (but it could be c1 or c2), I get this SQL query:
>> >
>> > ALTER TYPE s1.ty2
>> >  ADD ATTRIBUTE c3 xml;
>> > ALTER TYPE s1.ty2
>> >  DROP ATTRIBUTE c3;
>> >
>> > Remember that, on pgAdmin, it shows the list this way:
>> >    c1 integer,
>> >    c2 integer,
>> >    c3 xml,
>> >    c4 integer
>> >
>> > I click OK, and get back to the properties dialog. pgAdmin now shows the
>> > list this way:
>> >    c1 integer,
>> >    c2 integer,
>> >    c4 integer
>> >    c3 xml,
>> >
>> > Which is true. We drop the attribute and add another one, which will be
>> > at the end of the list.
>>
>> I have a solution.  It seems I overlooked the alter attribute
>> capabilities.  We can just do:
>>
>> ALTER TYPE s1.ty2
>> ALTER ATTRIBUTE c3 TYPE xml;
>>
>> That will preserve its position without ever having to drop it.  I'm
>> not sure why I didn't see it before.
>>
>
> Can you fix your patch to also use this syntax?

Yes, I'll try to fix both issues.  Thanks for testing it.  I'll be
back with a patch shortly.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company