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