Re: Feature: temporary materialized views
От | Michael Paquier |
---|---|
Тема | Re: Feature: temporary materialized views |
Дата | |
Msg-id | 20190206091817.GB14980@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Feature: temporary materialized views (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: Feature: temporary materialized views
|
Список | pgsql-hackers |
On Tue, Feb 05, 2019 at 06:56:00PM +0100, Andreas Karlsson wrote: > I guess that I could fix that for the second case as soon as I understand > how much of the portal stuff can be skipped in ExecuteQuery(). But I am not > sure what we should do with EXPLAIN ANALYZE ... NO DATA. It feels like a > contraction to me. Should we just raise an error? Or should we try to > preserve the current behavior where you see something like the > below? This grammar is documented, so it seems to me that it would be just annoying for users relying on it to throw an error for a pattern that simply worked, particularly if a driver layer is using it. The issue this outlines is that we have a gap in the tests for a subset of the grammar, which is not a good thing. If I put Assert(!into->skipData) at the beginning of intorel_startup() then the main regression test suite is able to pass, both on HEAD and with your patch. There is one test for CTAS EXECUTE in prepare.sql, so let's add a pattern with WITH NO DATA there for the first pattern. Adding a second test with EXPLAIN SELECT INTO into select_into.sql also looks like a good thing. Attached is a patch to do that and close the gap. With that, we will be able to check for inconsistencies better when working on the follow-up patches. What do you think? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: