Re: Container Types - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Container Types
Date
Msg-id 20231025230151.mly2jfgchcbg5kpp@awork3.anarazel.de
Whole thread Raw
In response to Re: Container Types  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Container Types
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: post-recovery amcheck expectations
Next
From: "David G. Johnston"
Date:
Subject: Re: Document aggregate functions better w.r.t. ORDER BY