Re: Feature: temporary materialized views - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: Feature: temporary materialized views
Date
Msg-id d76e77a2-3d6c-f82a-585b-36fad3873875@proxel.se
Whole thread Raw
In response to Re: Feature: temporary materialized views  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feature: temporary materialized views  (Andreas Karlsson <andreas@proxel.se>)
List 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Thread-unsafe coding in ecpg
Next
From: Chapman Flack
Date:
Subject: Re: PostgreSQL vs SQL/XML Standards