composite types not pushing down

[rcronin]

I am trying to test this locally after building pg_lake for docker. When I do the following:

create type accessorial as (
    code text,
    charges numeric
                           );

create table fact_freight_bill_heap as
select 1234334 pro_number, 100.11 net_revenue, array[row('LIFT', 25.00)]::accessorial[] accessorials;

create table fact_freight_bill_iceberg using iceberg as
select pro_number, net_revenue, accessorials
from fact_freight_bill_heap;

I get this error:

[42804] ERROR: column "accessorials" is of type lake_struct.code_charges_a8759c4a[] but expression is of type accessorial[]
Hint: You will need to rewrite or cast the expression.

Originally posted by @rcronin in #535 (comment)

[sfc-gh-mslot]

Thanks for the repro. The title is a bit misleading, composite types are fine here. The trigger is the unbounded numeric in charges.

Iceberg cannot store a numeric with no declared precision, so with pg_lake_iceberg.unsupported_numeric_as_double on (the default) we rewrite the column to use double instead. When the numeric is nested, rewriting it means rebuilding the composite around it, so we create a new type in the lake_struct schema and the table gets declared as lake_struct.code_charges_a8759c4a[] instead of accessorial[]. CREATE TABLE AS SELECT then runs an internal INSERT ... SELECT, and there is no cast between the two composite types, which is the error you get.

It is not specific to CTAS, the explicit version fails the same way:

create table ice (pro_number int, accessorials accessorial[]) using iceberg;
NOTICE:  column "accessorials" has type that cannot be stored as an Iceberg decimal, converting to double precision

\d ice
 accessorials | lake_struct.code_charges_a8759c4a[]

insert into ice select pro_number, accessorials from fact_freight_bill_heap;
ERROR:  column "accessorials" is of type lake_struct.code_charges_a8759c4a[] but expression is of type accessorial[]

This is a regression from #257 and #273, first released in v3.3.0. Up to v3.2.2 an unbounded numeric was accepted and stored as decimal(38,9) with no type rewrite, so the composite type you declared survived.

For now, giving the field a bounded precision avoids it, and matches what the older versions stored:

create type accessorial as (code text, charges numeric(38,9));

double precision also works if you do not need the exact decimal. Setting pg_lake_iceberg.unsupported_numeric_as_double = off does not help, that path rejects the column outright.

The fix is probably to keep accessorial[] as the Postgres column type and only map numeric to double in the Iceberg schema, which is where we already handle this kind of difference for compatibility modes. I will look into it.

[rcronin]

Ah, this makes sense. Appreciate the explanation here. Thanks!