Re: Anonymous record member access

From: Ken Harris <kengruven(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Anonymous record member access
Date: 2026-09-20 18:36:23
Message-ID: CALoxLVrtVByp=dMEUb1PQc-vT3-+7gvrpHf1DRy4P1T96K+4+Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Thanks for the info. I guess my big lesson here is: (plpg)sql is much more
statically typed than I thought.

I was hoping for a function like:

CREATE FUNCTION field_for_composite_value(record, text) RETURNS any AS $$
return record[text]
$$ LANGUAGE plpython3u IMMUTABLE STRICT;

but pretty much all of the "pseudo-types" are unavailable to all four of
the built-in extension languages. (In fact, "any" is so unsupported that
it's a syntax error here!) I guess I need to figure out C extensions for
that.

The bigger picture is that I wanted to write something kind of like
to_json() which dumps composite values recursively, but with a different
format. (There are also *_to_xml() functions, but unlike JSON, they output
composite values as plain strings like (a,,,b) -- and also only operate on
cursor/table/query/database, not individual values.) I'm still playing
with these, and I'm not sure if I can use them to fake a
`field_for_composite_value()` function or not.

Thanks again.

- Ken

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message shihao zhong 2026-09-20 19:24:55 Re: 9.4.1. format
Previous Message PG Doc comments form 2026-09-19 14:49:55 E.6.3.2.1. Constraints