Container Types

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Container Types
Date: 2022-12-20 09:24:22
Message-ID: 95f1bdf8-a87e-f02f-7922-bb39627508bf@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The standard has several constructs for creating new types from other
types. I don't mean anything like CREATE TYPE here, I mean things like
this:

- ROW(a, b, c), (<explicit row value constructor>)
- ARRAY[a, b, c], (<array value constructor by enumeration>)
- PERIOD(a, b), (<period predicand>)
- MULTISET[a, b, c], (<multiset value constructor by enumeration>)
- MDARRAY[x(1:3)][a, b, c], (<md-array value constructor by enumeration>)

I am not sure what magic we use for the row value constructor. We
handle ARRAY by creating an array type for every non-array type that is
created. Periods are very similar to range types and we have to create
new functions such as int4range(a,b) and int8range(a,b) instead of some
kind of generic RANGE(a, b, '[)') and not worrying about what the type
is as long as there is a btree opclass for it.

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.

For those who know the code much better than I do, what would be a
plausible way forward to support these containers?
--
Vik Fearing

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-12-20 09:31:54 Re: Add enable_presorted_aggregate GUC
Previous Message Hayato Kuroda (Fujitsu) 2022-12-20 09:16:29 RE: Force streaming every change in logical decoding