Re: Feature: temporary materialized views

Поиск
Список
Период
Сортировка
От Andreas Karlsson
Тема Re: Feature: temporary materialized views
Дата
Msg-id d76e77a2-3d6c-f82a-585b-36fad3873875@proxel.se
обсуждение исходный текст
Ответ на Re: Feature: temporary materialized views  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Feature: temporary materialized views  (Andreas Karlsson <andreas@proxel.se>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Thread-unsafe coding in ecpg
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: PostgreSQL vs SQL/XML Standards