Good question. In my case they should be different until someone starts to do operations with them. For example: DECIMAL_1 extends DECIMAL(10, 3), DECIMAL_2 extends DECIMAL(10,3) are different types, but when someone starts to use them `1::DECIMAL_1 + 2::DECIMAL_2`, `1::DECIMAL_1 = 2::DECIMAL_2` they should behave like the same type. But it is only my case.
"One approach is to add a new kind of metadata. It can propagate through > the RelNode graph in parallel with the type information. (Constraints > already do this.)" Can you point me where I can find this code ? On Sat, Aug 20, 2022 at 1:32 AM Julian Hyde <[email protected]> wrote: > I’ve thought about adding annotations to (the internal representation of) > Calcite types. We never got very far with it. It would be tricky because we > canonize types, and so if you have two instances that represent, say, > DECIMAL(10, 3) with different annotations, are they the same type? > > One approach is to add a new kind of metadata. It can propagate through > the RelNode graph in parallel with the type information. (Constraints > already do this.) > > Julian > > > > On Aug 19, 2022, at 7:54 AM, Dmitry Sysolyatin <[email protected]> > wrote: > > > > Hello! > > I am working on emulating a Postgres server and am faced with the > following > > problem: > > > > Postgres `pg_catalog` schema has custom types like `name`, those types > can > > be easily mapped to calcite basic types. The problem is that several > types > > in PG can be mapped to one calcite type (for example: `name` and > `varchar` > > in PG are mapped to `varchar` type in calcite) but postgres has a unique > id > > for every type. > > Some PG clients like Power BI require the right id for the column. > > Planner.validateAndGetType() returns row data type for the query, but I > can > > not derive pg type id from this data type, because calcite data type can > > correspond to several PG types. > > > > One solution would be putting some extra information to RelDataType when > > the table structure is defined and somehow extracting it when the row > type > > for query is inferred. > > > > I will be very grateful for your help > >
