On 3/15/19 3:19 AM, Mitar wrote:
On Thu, Mar 14, 2019 at 7:56 AM Andreas Karlsson wrote:
Yeah, your patch is sadly stuck behind the refactoring, and the
refactoring proved to be harder to do than I initially thought. The
different code paths for executing CREATE MATERIALIZED VIEW are so
differ
Hi!
On Thu, Mar 14, 2019 at 7:56 AM Andreas Karlsson wrote:
> Yeah, your patch is sadly stuck behind the refactoring, and the
> refactoring proved to be harder to do than I initially thought. The
> different code paths for executing CREATE MATERIALIZED VIEW are so
> different that it is hard to f
On 3/14/19 9:13 AM, Mitar wrote:> I just want to make sure if I
understand correctly. But my initial
proposal/patch is currently waiting first for all patches for the
refactoring to happen, which are done by amazing Andreas? This sounds
good to me and I see a lot of progress/work has been done an
Hi!
I just want to make sure if I understand correctly. But my initial
proposal/patch is currently waiting first for all patches for the
refactoring to happen, which are done by amazing Andreas? This sounds
good to me and I see a lot of progress/work has been done and I am OK
with waiting. Please
On 3/8/19 2:38 AM, Michael Paquier wrote:
On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote:
I think a new patch is required here so I have marked this Waiting on
Author. cfbot is certainly not happy and anyone trying to review is going
to have hard time trying to determine what to r
On 3/8/19 3:38 AM, Michael Paquier wrote:
On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote:
I think a new patch is required here so I have marked this Waiting on
Author. cfbot is certainly not happy and anyone trying to review is going
to have hard time trying to determine what to r
On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote:
> I think a new patch is required here so I have marked this Waiting on
> Author. cfbot is certainly not happy and anyone trying to review is going
> to have hard time trying to determine what to review.
I would recommend to mark this
On 2/7/19 2:23 AM, Michael Paquier wrote:
On Wed, Feb 06, 2019 at 05:05:56PM +0100, Andreas Karlsson wrote:
On 2/6/19 10:18 AM, Michael Paquier wrote:
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
On Wed, Feb 06, 2019 at 05:05:56PM +0100, Andreas Karlsson wrote:
> On 2/6/19 10:18 AM, Michael Paquier wrote:
>> 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?
>
> I
On 2/6/19 10:18 AM, Michael Paquier wrote:
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?
I approve. I was when testing this stuff that I found the IF NOT EXISTS
issue.
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
> co
On 2/5/19 6:56 PM, Andreas Karlsson wrote:
On 2/5/19 12:36 PM, Michael Paquier wrote:> - skipData is visibly always
false.
> We may want to keep skipData to have an assertion at the beginning of
> inforel_startup for sanity purposes though.
This is not true in this version of the patch. The fo
On 2/5/19 12:36 PM, Michael Paquier wrote:> - skipData is visibly always
false.
> We may want to keep skipData to have an assertion at the beginning of
> inforel_startup for sanity purposes though.
This is not true in this version of the patch. The following two cases
would crash if we add such
Hi Andreas,
On Tue, Feb 05, 2019 at 12:59:12PM +0900, Michael Paquier wrote:
> Now... You have on this thread all the audience which already worked
> on 874fe3a. And I am just looking at this patch, evaluating the
> behavior change this is introducing. Still I would recommend a
> separate threa
On Mon, Feb 04, 2019 at 04:10:09PM +0100, Andreas Karlsson wrote:
> Should I submit it as a separate CF entry or is it easiest if my refactoring
> and Mi Tar's feature are reviewed together?
The refactoring patch is talking about changing the way objects are
created within a CTAS, which is quite d
On 2/4/19 7:09 AM, Michael Paquier wrote:
On Tue, Jan 22, 2019 at 03:10:17AM +0100, Andreas Karlsson wrote:
On 1/21/19 3:31 AM, Andreas Karlsson wrote:
Here is a a stab at refactoring this so the object creation does not
happen in a callback.
Rebased my patch on top of Andres's pluggable stor
On Tue, Jan 22, 2019 at 03:10:17AM +0100, Andreas Karlsson wrote:
> On 1/21/19 3:31 AM, Andreas Karlsson wrote:
> > Here is a a stab at refactoring this so the object creation does not
> > happen in a callback.
>
> Rebased my patch on top of Andres's pluggable storage patches. Plus some
> minor st
On 1/21/19 3:31 AM, Andreas Karlsson wrote:
Here is a a stab at refactoring this so the object creation does not
happen in a callback.
Rebased my patch on top of Andres's pluggable storage patches. Plus some
minor style changes.
Andreas
diff --git a/src/backend/commands/createas.c b/src/back
On 1/18/19 8:32 PM, Mitar wrote:
On Fri, Jan 18, 2019 at 7:18 AM Andreas Karlsson wrote:
These rules are usually pretty easy to add. Just take a look in
src/bin/psql/tab-complete.c to see how it is usually done.
Thanks. I have added the auto-complete and attached a new patch.
Hm, I do not t
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
Hi!
On Fri, Jan 18, 2019 at 7:18 AM Andreas Karlsson wrote:
> These rules are usually pretty easy to add. Just take a look in
> src/bin/psql/tab-complete.c to see how it is usually done.
Thanks. I have added the auto-complete and attached a new patch.
> I might take a stab at refactoring this m
On 1/18/19 2:53 AM, Mitar wrote:> On Thu, Jan 17, 2019 at 2:40 PM
Andreas Karlsson wrote:
I did some functional testing today and everything seems to work as
expected other than that the tab completion for psql seems to be missing.
Thanks. I can add those as soon as I figure how. :-)
These r
Hi!
On Thu, Jan 17, 2019 at 2:40 PM Andreas Karlsson wrote:
> I did some functional testing today and everything seems to work as
> expected other than that the tab completion for psql seems to be missing.
Thanks. I can add those as soon as I figure how. :-)
So what are next steps here besides
Hi!
On Thu, Jan 17, 2019 at 9:53 AM Andreas Karlsson wrote:
> > What is the stumbling block to just leaving that alone?
>
> I think the issue Mitar ran into is that the temporary materialized view
> is created in the rStartup callback of the receiver which happens after
> SECURITY_RESTRICTED_OPER
On 1/11/19 8:47 PM, Mitar wrote:
Thanks for doing the review!
I did some functional testing today and everything seems to work as
expected other than that the tab completion for psql seems to be missing.
Andreas
Andreas Karlsson writes:
> On 1/17/19 4:57 PM, Tom Lane wrote:
>> What is the stumbling block to just leaving that alone?
> I think the issue Mitar ran into is that the temporary materialized view
> is created in the rStartup callback of the receiver which happens after
> SECURITY_RESTRICTED_OP
On 1/17/19 4:57 PM, Tom Lane wrote:
Andreas Karlsson writes:
On 1/11/19 8:47 PM, Mitar wrote:
Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
ExecCreateTableAs()?
The comment there said that this is not really necessary for security:
"This is not necessary for security, bu
Andreas Karlsson writes:
> On 1/11/19 8:47 PM, Mitar wrote:
>>> Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
>>> ExecCreateTableAs()?
>> The comment there said that this is not really necessary for security:
>> "This is not necessary for security, but this keeps the behavior
On 1/11/19 8:47 PM, Mitar wrote:
In create_ctas_internal() why do you copy the relation even when you do
not modify it?
I was modelling this after code in view.c [1]. I can move copy into the "if".
Makes sense.
Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
ExecCreateTabl
Hi!
On Fri, Jan 11, 2019 at 8:51 AM Andreas Karlsson wrote:
> Her is quick initial review. I will do more testing later.
Thanks for doing the review!
> In create_ctas_internal() why do you copy the relation even when you do
> not modify it?
I was modelling this after code in view.c [1]. I can
On 12/28/18 8:48 AM, Mitar wrote:> One more version of the patch with
more deterministic tests.
Her is quick initial review. I will do more testing later.
It applies builds and passes the tests.
The feature seems useful and also improves consistency, if we have
temporary tables and temporary
Hi!
One more version of the patch with more deterministic tests.
Mitar
On Thu, Dec 27, 2018 at 10:35 AM Mitar wrote:
>
> Hi!
>
> Thanks, I did it.
>
> I am attaching a new version of the patch with few more lines added to tests.
>
> I noticed that there is no good summary of the latest patch,
Hi!
Thanks, I did it.
I am attaching a new version of the patch with few more lines added to tests.
I noticed that there is no good summary of the latest patch, so let me
make it here:
So the latest version of the patch adds an option for "temporary"
materialized views. Such materialized views
On 2018-Dec-27, Mitar wrote:
> Hi!
>
> I made a new version of the patch. I added tests and changes to the
> docs and made sure various other aspects of this change for as well. I
> think this now makes temporary materialized views fully implemented
> and that in my view patch is complete. If the
Hi!
I made a new version of the patch. I added tests and changes to the
docs and made sure various other aspects of this change for as well. I
think this now makes temporary materialized views fully implemented
and that in my view patch is complete. If there is anything else to
add, please let me
On 2018-Dec-26, Mitar wrote:
> OptTemp seems to have a misleading warning in some cases when it is
> not used on tables though:
>
> "GLOBAL is deprecated in temporary table creation"
>
> Should we change this language to something else? "GLOBAL is
> deprecated in temporary object creation"? Base
st 26. 12. 2018 v 18:20 odesÃlatel Mitar napsal:
> Hi!
>
> On Wed, Dec 26, 2018 at 9:00 AM Alvaro Herrera
> wrote:
> > I think MVs that are dropped at session end are a sensible feature.
>
> Thanks.
>
> > I probably wouldn't go as far as allowing ON COMMIT actions, though
>
> I agree. I do not s
Hi!
On Wed, Dec 26, 2018 at 9:00 AM Alvaro Herrera wrote:
> I think MVs that are dropped at session end are a sensible feature.
Thanks.
> I probably wouldn't go as far as allowing ON COMMIT actions, though
I agree. I do not see much usefulness for it. The only use case I can
think of would be
On 2018-Dec-25, Mitar wrote:
> Sometimes materialized views are used to cache a complex query on
> which a client works. But after client disconnects, the materialized
> view could be deleted. Regular VIEWs and TABLEs both have support for
> temporary versions which get automatically dropped at th
39 matches
Mail list logo
