|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
|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|