Re: Virtual generated columns

Vik Fearing <vik@postgresfriends.org>

From: Vik Fearing <vik@postgresfriends.org>
To: Marcos Pegoraro <marcos@f10.com.br>, Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, jian he <jian.universality@gmail.com>, Dean Rasheed <dean.a.rasheed@gmail.com>
Date: 2025-01-08T19:23:35Z
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__.

On 08/01/2025 20:19, Marcos Pegoraro wrote:
> Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut 
> <peter@eisentraut.org> escreveu:
>
>     Here is a new patch version where I have gathered various pieces of
>     feedback and improvement suggestions that are scattered over this
>     thread.  I hope I got them all.  I will respond to the respective
>     messages directly to give my response to each item.
>
>
> This new version you are not accepting subqueries, like previous ones. 
> But we can create an immutable SQL function which will do the same. 
> Wouldn't it be better to explain that on DOCs ?
>
> create table Orders(Order_ID integer not null primary key, Customer_ID 
> integer references Customer);
> create function lkCustomer(integer) returns text language sql 
> immutable as $function$select Name from Customer where Customer_ID = 
> $1;$function$;
> alter table Orders add lkCustomer text generated always as 
> (lkCustomer(Customer_ID)) stored;


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.

-- 

Vik Fearing