Re: Virtual generated columns

Marcos Pegoraro <marcos@f10.com.br>

From: Marcos Pegoraro <marcos@f10.com.br>
To: Vik Fearing <vik@postgresfriends.org>
Cc: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>, jian he <jian.universality@gmail.com>, Dean Rasheed <dean.a.rasheed@gmail.com>
Date: 2025-01-08T19:29:51Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Expand virtual generated columns for ALTER COLUMN TYPE

  2. Eliminate code duplication in replace_rte_variables callbacks

  3. Expand virtual generated columns in the planner

  4. Virtual generated columns

  5. Additional tests for stored generated columns

  6. Improve generated_stored test

  7. Fix handling of CREATE DOMAIN with GENERATED constraint syntax

  8. Add pg_constraint rows for not-null constraints

  9. Put generated_stored test objects in a schema

  10. Rename regress test generated to generated_stored

  11. Small code simplification

  12. Remove useless code

  13. Remove useless initializations

  14. doc: Clarify that pg_attrdef also stores generation expressions

  15. Clean out column-level pg_init_privs entries when dropping tables.

  16. Re-implement the ereport() macro using __VA_ARGS__.

Em qua., 8 de jan. de 2025 às 16:23, Vik Fearing <vik@postgresfriends.org>
escreveu:

> This is lying to the planner, and you get to enjoy whatever breaks
> because of it.  A function that accesses external data is not immutable;
> it is stable at best.
>

I understand that, but it's not documented, so users can think that way is
fine. So, it would be good to explain why this way could break this or that.

regards
Marcos