Re: Container Types

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Container Types
Date: 2023-10-26 06:13:31
Message-ID: 3e4a42efcb8a42d5fa9ea15adcef78eb466346c4.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2023-10-25 at 16:01 -0700, Andres Freund wrote:
> I'd look whether you can generalize that infrastructure.

I had briefly looked at using the record type mechanism before, and it
seemed like a challenge because it doesn't really work when passing
through a function call:

CREATE TABLE t(a INT, b TEXT);
INSERT INTO t VALUES(1, 'one');
CREATE FUNCTION id(RECORD) RETURNS RECORD LANGUAGE plpgsql AS
$$ BEGIN RETURN $1; END; $$;
SELECT t.a FROM t; -- 1
SELECT (id(t)).a FROM t; -- ERROR

But now that I think about it, that's really a type inference
limitation, and that needs to be solved regardless.

After the type inference figures out what the right type is, then I
think you're right that an OID is not required to track it, and however
we do track it should be able to reuse some of the existing
infrastructure for dealing with record types.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-10-26 06:28:32 Re: Show WAL write and fsync stats in pg_stat_io
Previous Message David G. Johnston 2023-10-26 05:34:10 Re: Document aggregate functions better w.r.t. ORDER BY