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
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 |