Hi, On 2023-10-25 15:03:04 -0700, Jeff Davis wrote: > 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 > ethe 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.
I don't think particularly like the idea of an in-memory pg_type entry. But I'm not sure we need that anyway - we already have this problem with record types. We support both named record types (tables and explicitly created composite types) and ad-hoc ones (created if you write ROW(foo, bar) or something like that). If a record's typmod is negative, it refers to an anonymous row type, if positive it's a named typmod. We even have support for sharing such ad-hoc rowtypes across backends for parallel query... I'd look whether you can generalize that infrastructure. Greetings, Andres Freund
