Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > I received the following pg_migrator bug report today and was able to
> > reproduce the reported failure when using composite types:
>
> > test=> SELECT * FROM breakmigrator;
> > ERROR: cache lookup failed for type 27604
>
> Hm ... has anyone tested pg_migrator using either composite types or
> arrays of user-defined types? Both of them have got user-defined-type
> OIDs in on-disk data, now that I think about it. For that matter, enums
> are going to be a problem too.
Yep, I realized that since I posted. It seems composite types are
mini-heap tuples, except that instead of xmin/xmax, they have type
information:
typedef struct DatumTupleFields
{
int32 datum_len_; /* varlena header (do not touch
directly!) */
int32 datum_typmod; /* -1, or identifier of a record type */
Oid datum_typeid; /* composite type OID, or RECORDOID */
/*
* Note: field ordering is chosen with thought that Oid might
someday
* widen to 64 bits.
*/
} DatumTupleFields;
datum_typeid is where the composite type oid is stored.
Do we have no composite types in the regression tests, or do we not
store any in the database? Same the enums.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
