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
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
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
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
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
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
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
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
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
>
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)
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();
>
>
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
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
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
are not bypassing the call to
> ExecutorCheckPerms_hook_type. Unless I miss anything else, I think it
> makes sense to skip ExecCheckRTPerms() for CTAS WITH NO DATA.
Oh, I see what you mean here. If you have a EXPLAIN ANALYZE CTAS or
CTAS EXECUTE, then we forbid the creation of the table if the user has
no INSER
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
ission will be called from DoCopy()).
Effectively, we are not bypassing the call to
ExecutorCheckPerms_hook_type. Unless I miss anything else, I think it
makes sense to skip ExecCheckRTPerms() for CTAS WITH NO DATA.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
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
>
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
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
> > >
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
> >
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.
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
