Hi

ne 20. 9. 2026 v 20:36 odesílatel Ken Harris <[email protected]> napsal:

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

PostgreSQL is a very static system - there is a basic rule - the complete
structure of the result must be known in planning time - before query
execution.
There can be some exceptions inside some subsystems - but at the level of
top query, this rule is absolute. There are partial solutions - you can use
json, xml, hstore, arrays,
but it is always partial solution.

Most SQL databases are "compilers" - and it is reason, why these systems
are static.

Some other databases are "dynamic" in execution of SQL procedures executed
by CALL statement. CALL statement has not execution plan, so it is
possible. But PostgreSQL stored procedures cannot to return recordset, so
at the end, it is static too (on Postgres).

Generally, don't try to design too dynamic system inside PostgreSQL stored
procedures. It doesn't work (without own dedicated extensions). But still
extensions cannot to force dynamic result structure to top query.

Regards

Pavel


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

Reply via email to