From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Nurul Karim Rafi <rafikarim1414(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Materialized view in Postgres from the variables rather than SQL query results |
Date: | 2023-12-01 13:40:16 |
Message-ID: | CAKFQuwb+LNNpwp6gD8XkehszkDCWRLJUCnk5gpWjAWuQELJTAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
This mailing list is for discussing the development of patches to the
PostgreSQL code base. Please send your request for help to a more
appropriate list - specifically the -general list.
David J.
On Thursday, November 30, 2023, Nurul Karim Rafi <rafikarim1414(at)gmail(dot)com>
wrote:
> I have a stored procedure in Postgres. I have generated some variables in
> that procedure. These variables are generated inside a loop of query
> result. Suppose if i have 10 rows from my query then for 10 times I am
> generating those variables.
>
> Now I want to create a materialized view where these variables will be the
> columns and every row will have values of those variables generated in
> every iteration of that loop.
>
> What can be the better approach for this?
>
> I can create a temporary table with those variables and insert values in
> every iteration of that loop but that will not serve my purpose. Because I
> want to drop my existing table where all the values are available and
> columns are those variables. My target is to make a materialized view with
> those variables so that I can get rid of that parent table.
>
> Best Regards
>
> *Rafi*
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-12-01 14:00:01 | Re: Refactoring backend fork+exec code |
Previous Message | Ashutosh Bapat | 2023-12-01 13:19:46 | Re: Postgres Partitions Limitations (5.11.2.3) |