Re: Feature: temporary materialized views

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mitar <mmitar(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Feature: temporary materialized views
Date: 2019-01-21 02:31:55
Message-ID: d76e77a2-3d6c-f82a-585b-36fad3873875@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/17/19 8:31 PM, Tom Lane wrote:
> Creating the view object inside the rStartup callback is itself pretty
> much of a kluge; you'd expect that to happen earlier. I think the
> reason it was done that way was it was easier to find out the view's
> column set there, but I'm sure we can find another way --- doing the
> object creation more like a regular view does it is the obvious approach.

Here is a a stab at refactoring this so the object creation does not
happen in a callback. I am not that fond of the new API, but given how
different all the various callers of CreateIntoRelDestReceiver() are I
had no better idea.

The idea behind the patch is to always create the empty
table/materialized view before executing the query and do it in one more
unified code path, and then later populate it unless NO DATA was
specified. I feel this makes the code easier to follow.

This patch introduces a small behavioral change, as can be seen from the
diff in the test suite, where since the object creation is moved earlier
the CTAS query snapshot will for example see the newly created table.
The new behavior seems more correct to me, but maybe I am missing some
unintended consequences.

Andreas

Attachment Content-Type Size
refactor-ctas-v1.patch text/x-patch 17.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-01-21 02:41:44 Re: PostgreSQL vs SQL/XML Standards
Previous Message Tom Lane 2019-01-21 02:20:55 Re: Thread-unsafe coding in ecpg