Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Oleg wrote:
>>> CREATE CAST (tmp_table AS composite_ad_texts)
>>> WITHOUT FUNCTION AS ASSIGNMENT;
>
>> "WITHOUT FUNCTION" can only be used when both types are binary
>> compatible. You might think that two composite types with the same
>> fields are, but they're not: we store the OID of the composite type in
>> the records.
>
> Although this qualifies as pilot error (superusers are expected to know
> what they're doing), should we attempt to prevent the case?
We can't detect binary-incompatibility in general, so I presume you
meant just for the case of composite types. Hmm, I guess we could do it
in that case.
> It doesn't
> seem like a tremendously unlikely mistake to make, and AFAICS there is
> no easy way to recover your data once you've done it.
I believe the command has been like that for a long time, and this is
the first time someone managed to shoot one's foot. It was made much
worse by the ALTER TABLE and DROP TABLE. But yeah, it seems easy enough
to check for the composite types case, so let's do that.
Oleg replied off-list asking how to recover the data. I suggested
resetting the OID counter to the OID of the dropped table with
pg_resetxlog, recreating it, and doing a pg_dump/restore.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com