On Tue, 2022-12-20 at 10:24 +0100, Vik Fearing wrote:
> Obviously there would have to be an actual type in order to store it
> in
> a table, but what I am most interested in here is being able to
> create
> them on the fly. I do not think it is feasible to create N new types
> for every type like we do for arrays on the off-chance you would want
> to
> put it in a PERIOD for example.
By "on the fly" do you mean when creating real objects, like a table?
In that case it might not be so hard, because we can just create an
ordinary entry in pg_type.
But for this to be a complete feature, I think we need the container
types to be useful when constructed within a query, too. E.g.
SELECT two_things(v1, v2) FROM foo;
where the result of two_things is some new type two_things_int_text
which is based on the types of v1 and v2 and has never been used
before.
I don't think it's reasonable to create a permanent pg_type entry on
the fly to answer a read-only query. But we could introduce some notion
of an ephemeral in-memory pg_type entry with its own OID, and create
that on the fly.
One way to do that might be to reserve some of the system OID space
(e.g. 15000-16000) for OIDs for temporary catalog entries, and then
have some in-memory structure that holds those temporary entries. Any
lookups in that range would search the in-memory structure instead of
the real catalog. All of this is easier said than done, but I think it
could work.
We'd also need to think about how to infer types through a container
type, e.g.
SELECT second_thing(two_things(v1,v2)) FROM foo;
should infer that the return type of second_thing() is the type of v2.
To do that, perhaps pg_proc entries can include some kind of type
sublanguage to do this inference, e.g. "a, b -> b" for second_thing(),
or "a, b -> a" for first_thing().
Regards,
Jeff Davis
