On Fri, Nov 20, 2020 at 03:04:57PM +0530, Bharath Rupireddy wrote:
> Thanks! Attaching the patch. Please review it.
Thanks. I have removed the references to the INSERT check in the
comments and the docs, because that would be confusing as it refers
to something we don't do anymore now with this p
On Fri, Nov 20, 2020 at 11:07 AM Michael Paquier wrote:
>
> Thanks. Based on what Peter has said, the ACL_INSERT check in
> intorel_startup() could just be removed, and the tests of matview.sql
> and select_into.sql would need some cleanup. We could keep around
> some scenarios with some follow-
On Fri, Nov 20, 2020 at 12:59 PM Peter Eisentraut
wrote:
>
> On 2020-11-20 06:37, Michael Paquier wrote:
> >>> But if you consider materialized views as a variant of normal views,
> >>> then the INSERT privilege would be applicable if you pass an INSERT on
> >>> the materialized view through to th
On 2020-11-20 06:37, Michael Paquier wrote:
But if you consider materialized views as a variant of normal views,
then the INSERT privilege would be applicable if you pass an INSERT on
the materialized view through to the underlying tables, like for a view.
INSERT to materialized views is not sup
On 2020-11-19 17:35, Bharath Rupireddy wrote:
So, should we be doing it this way?
For CTAS: retain the existing CREATE privilege check and remove the
INSERT privilege check altogether for all the cases i.e. with data,
with no data, explain analyze, plain, with execute?
For CREATE MATERIALIZED VI
On Thu, Nov 19, 2020 at 10:05:19PM +0530, Bharath Rupireddy wrote:
> On Thu, Nov 19, 2020 at 8:47 PM Peter Eisentraut
> wrote:
>> Materialized views are not in the SQL standard.
>>
>> But if you consider materialized views as a variant of normal views,
>> then the INSERT privilege would be applic
On Thu, Nov 19, 2020 at 8:47 PM Peter Eisentraut
wrote:
>
> On 2020-11-17 02:32, Michael Paquier wrote:
> >> The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
> >> executed without further Access Rule checking", which means the INSERT
> >> privilege shouldn't be required a
On 2020-11-17 02:32, Michael Paquier wrote:
The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
executed without further Access Rule checking", which means the INSERT
privilege shouldn't be required at all. I suggest we consider doing that
instead. I don't see a use for t
On Mon, Nov 16, 2020 at 04:01:33PM +0100, Peter Eisentraut wrote:
> While this patch was nice enough to update the documentation about the
> requirement of the INSERT privilege, this is maybe more confusing now: How
> could a new table not have INSERT privilege? Yes, you can do that with
> default
On 2020-11-16 04:04, Michael Paquier wrote:
On Fri, Nov 13, 2020 at 12:58:52PM +0530, Bharath Rupireddy wrote:
It's not required to set bistate to null as we have allocated myState
with palloc0 in CreateIntoRelDestReceiver, it will anyways be null.
if (!into->skipData)
myState->bista
On Fri, Nov 13, 2020 at 12:58:52PM +0530, Bharath Rupireddy wrote:
> It's not required to set bistate to null as we have allocated myState
> with palloc0 in CreateIntoRelDestReceiver, it will anyways be null.
> if (!into->skipData)
> myState->bistate = GetBulkInsertState();
>
> Attaching
Thanks for the comments.
On Fri, Nov 13, 2020 at 9:19 AM Michael Paquier wrote:
>
> Let's move any tests related to matviews to matviews.sql. It does not
> seem consistent to me to have those tests in a test path reserved to
> CTAS, though I agree that there is some overlap and that setting up
>
On Thu, Nov 12, 2020 at 04:17:43PM +0530, Bharath Rupireddy wrote:
> On HEAD/master, the behaviour is as follows: a) for plain CTAS WITH NO
> DATA, ExecCheckRTPerms() will not be called. b) for explain analyze
> CTAS WITH NO DATA, ExecCheckRTPerms() will be called. So, we need a).
> This is what ex
Thanks for the comments.
On Thu, Nov 12, 2020 at 2:36 PM Michael Paquier wrote:
>
> On Wed, Nov 11, 2020 at 07:31:49PM +0530, Bharath Rupireddy wrote:
> > Yes we do not have anything related to permissions mentioned in the
> > documentation. So, I'm not adding it now.
>
> It would be good to clar
On Wed, Nov 11, 2020 at 07:31:49PM +0530, Bharath Rupireddy wrote:
> Yes we do not have anything related to permissions mentioned in the
> documentation. So, I'm not adding it now.
It would be good to clarify that in the docs while we are on it.
> Apart from the above, I also noticed that we unne
On Wed, Nov 11, 2020 at 01:34:05PM +0530, Bharath Rupireddy wrote:
> The ExecCheckRTPerms() with ACL_INSERT permission will be called
> before inserting the data to the table that's created with CREATE AS
> WITH NO DATA.
Perhaps you meant s/WITH NO DATA/WITH DATA/ here?
> The insertion into the t
On Tue, Nov 10, 2020 at 1:18 AM Anastasia Lubennikova
wrote:
>
> I took a look at the patch. It is quite simple, so no comments about the
> code. It would be good to add a test to select_into.sql to show that it
> only applies to 'WITH NO DATA' and that subsequent insertions will fail
> if permiss
On Wed, Nov 11, 2020 at 12:05 PM Michael Paquier wrote:
>
> On Mon, Nov 09, 2020 at 10:48:09PM +0300, Anastasia Lubennikova wrote:
> > I see Tom's objection above. Still, I tend to agree that if 'WITH NO DATA'
> > was specified explicitly, CREATE AS should behave more like a utility
> > statement
On Mon, Nov 09, 2020 at 10:48:09PM +0300, Anastasia Lubennikova wrote:
> I see Tom's objection above. Still, I tend to agree that if 'WITH NO DATA'
> was specified explicitly, CREATE AS should behave more like a utility
> statement rather than a regular query. So I think that this patch can be
> us
On 29.09.2020 14:39, Bharath Rupireddy wrote:
On Mon, Sep 28, 2020 at 7:48 PM Tom Lane wrote:
Bharath Rupireddy writes:
In case of CTAS with no data, we actually do not insert the tuples
into the created table, so we can skip checking for the insert
permissions. Anyways, the insert permission
On Tue, Sep 29, 2020 at 5:09 PM Bharath Rupireddy
wrote:
>
> On Mon, Sep 28, 2020 at 7:48 PM Tom Lane wrote:
> >
> > Bharath Rupireddy writes:
> > > In case of CTAS with no data, we actually do not insert the tuples
> > > into the created table, so we can skip checking for the insert
> > > permi
On Mon, Sep 28, 2020 at 7:48 PM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > In case of CTAS with no data, we actually do not insert the tuples
> > into the created table, so we can skip checking for the insert
> > permissions. Anyways, the insert permissions will be checked when the
> > tup
Bharath Rupireddy writes:
> In case of CTAS with no data, we actually do not insert the tuples
> into the created table, so we can skip checking for the insert
> permissions. Anyways, the insert permissions will be checked when the
> tuples are inserted into the table.
I'd argue this is wrong. Y
Hi,
In case of CTAS with no data, we actually do not insert the tuples
into the created table, so we can skip checking for the insert
permissions. Anyways, the insert permissions will be checked when the
tuples are inserted into the table.
Attaching a small patch doing $subject.
Thoughts?
With
24 matches
Mail list logo
