On 9 July 2011 13:25, Guillaume Lelarge <guilla...@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 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
