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
|
Список | 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 по дате отправления: