Обсуждение: BUG #6618: incorrect restore for composite columns when order changes

Поиск
Список
Период
Сортировка

BUG #6618: incorrect restore for composite columns when order changes

От
rikard.pavelic@zg.htnet.hr
Дата:
The following bug has been logged on the website:

Bug reference:      6618
Logged by:          Rikard Pavelic
Email address:      rikard.pavelic@zg.htnet.hr
PostgreSQL version: 9.1.3
Operating system:   Windows 7
Description:=20=20=20=20=20=20=20=20

We've run into another issue with composite types.
I've search internets but didn't find any reference to this, so I guess it's
not a documented problem.

Steps to reproduce problem:
1) create composite type
2) use composite type as column in a table
3) clone database
4) change order of attributes in cloned database
5) dump to plain sql with column names
6) restore sql dump to cloned database

Problem:
Composite type will be restored in order from original instead of cloned
database.

While I don't see a nice solution to this problem, it's not a too big issue
for us.
Just trying to document some more gotchas with composite types ;(

Re: BUG #6618: incorrect restore for composite columns when order changes

От
Tom Lane
Дата:
rikard.pavelic@zg.htnet.hr writes:
> Steps to reproduce problem:
> 1) create composite type
> 2) use composite type as column in a table
> 3) clone database
> 4) change order of attributes in cloned database
> 5) dump to plain sql with column names
> 6) restore sql dump to cloned database

There is no supported method for changing the order of attributes in a
composite type, so I wonder exactly how you did step 4.  If it involved
direct manipulation of the system catalogs, I would say this falls in
the category of "if you break it, you get to keep both pieces".

            regards, tom lane

Re: BUG #6618: incorrect restore for composite columns when order changes

От
Rikard Pavelic
Дата:
On 27.4.2012. 0:39, Tom Lane wrote:
>
> There is no supported method for changing the order of attributes in a
> composite type, so I wonder exactly how you did step 4.  If it involved
> direct manipulation of the system catalogs, I would say this falls in
> the category of "if you break it, you get to keep both pieces".
>
>             regards, tom lane
>

Well, there is no supported method for changing order of columns too, but
doesn't stop you from creating new and dropping old until you have
order which you want.

To be exact I didn't clone the database, I let our tool build it.
It built types with different order because our schema changed in the meantime.

Regards,
Rikard