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