On Wed, Jan 25, 2023 at 08:27:57PM -0800, Jeff Davis wrote:
> Committed these extra clarifications. Thank you.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, 2023-01-14 at 14:40 -0800, Nathan Bossart wrote:
> On Sat, Jan 14, 2023 at 10:40:40AM +0100, Gilles Darold wrote:
> > Nathan, please confirm and fix the status of this commit fest
> > entry.
>
> Yes, thank you for taking care of this. I believe the only changes
> in this
> patch that didn
On Sat, Jan 14, 2023 at 10:40:40AM +0100, Gilles Darold wrote:
> Nathan, please confirm and fix the status of this commit fest entry.
Yes, thank you for taking care of this. I believe the only changes in this
patch that didn't make it into ff9618e are the following documentation
adjustments. I'v
Le 11/01/2023 à 18:54, Nathan Bossart a écrit :
On Wed, Jan 11, 2023 at 02:22:26PM +0100, Gilles Darold wrote:
I'm moving this commitfest entry to Ready for Committers.
Thank you for reviewing.
I have changed the status to "Returned with feedback" as per commit
ff9618e8 this patch might not b
On Wed, Jan 11, 2023 at 02:22:26PM +0100, Gilles Darold wrote:
> I'm moving this commitfest entry to Ready for Committers.
Thank you for reviewing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Le 06/01/2023 à 01:26, Nathan Bossart a écrit :
Apparently I forgot to run all the tests before posting v4. Here is a new
version of the patch that should pass all tests.
Review status:
The patch applies and compiles without issues, make check and
checkinstall tests are running without erro
Apparently I forgot to run all the tests before posting v4. Here is a new
version of the patch that should pass all tests.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml
index 145101e6a5..749b410e16 100644
On Thu, Jan 05, 2023 at 02:38:58PM +0100, Gilles Darold wrote:
> This is a bit confusing, this commitfest entry patch is also included in an
> other commitfest entry [1] into patch v3-0001-fix-maintain-privs.patch with
> some additional conditions.
>
> Committers should be aware that this commitfe
Le 05/01/2023 à 06:12, Nathan Bossart a écrit :
On Wed, Jan 04, 2023 at 11:27:05PM +0100, Gilles Darold wrote:
Got it, this is patch add_cluster_skip_messages.patch . IMHO this patch
should be part of this commitfest as it is directly based on this one. You
could create a second patch here that
On Wed, Jan 04, 2023 at 11:27:05PM +0100, Gilles Darold wrote:
> Got it, this is patch add_cluster_skip_messages.patch . IMHO this patch
> should be part of this commitfest as it is directly based on this one. You
> could create a second patch here that adds the warning message so that
> committers
Le 04/01/2023 à 19:18, Nathan Bossart a écrit :
On Wed, Jan 04, 2023 at 02:25:13PM +0100, Gilles Darold wrote:
This is the current behavior of the CLUSTER command and current patch adds a
sentence about the silent behavior in the documentation. This is good but I
just want to ask if we could wan
On Wed, Jan 04, 2023 at 02:25:13PM +0100, Gilles Darold wrote:
> This is the current behavior of the CLUSTER command and current patch adds a
> sentence about the silent behavior in the documentation. This is good but I
> just want to ask if we could want to fix this behavior too or just keep
> thi
Le 16/12/2022 à 05:57, Nathan Bossart a écrit :
Here is a new version of the patch. I've moved the privilege checks to a
new function, and I added a note in the docs about clustering partitioned
tables in a transaction block (it's not allowed).
Getting into review of this patch I wonder why t
Here is a new version of the patch. I've moved the privilege checks to a
new function, and I added a note in the docs about clustering partitioned
tables in a transaction block (it's not allowed).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/sgml/ref/cluster
On Thu, Dec 08, 2022 at 04:08:40PM -0500, Robert Haas wrote:
> On Thu, Dec 8, 2022 at 1:13 PM Nathan Bossart
> wrote:
>> Currently, CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX (minus REINDEX
>> SCHEMA|DATABASE|SYSTEM) require ownership of the relation or superuser. In
>> fact, all three use
On Thu, Dec 8, 2022 at 1:13 PM Nathan Bossart wrote:
> On Thu, Dec 08, 2022 at 07:20:28AM -0500, Andrew Dunstan wrote:
> > We should probably talk about what the privileges should be, though. I
> > think there's a case to be made that CLUSTER should be governed by the
> > VACUUM privileges, given
On Thu, Dec 08, 2022 at 07:20:28AM -0500, Andrew Dunstan wrote:
> We should probably talk about what the privileges should be, though. I
> think there's a case to be made that CLUSTER should be governed by the
> VACUUM privileges, given how VACUUM FULL is now implemented.
Currently, CLUSTER, REFRE
On 2022-12-07 We 23:13, Nathan Bossart wrote:
> On Wed, Dec 07, 2022 at 08:25:59PM -0600, Justin Pryzby wrote:
>> Your patch makes it inconsistent with vacuum full, which is strange
>> because vacuum full calls cluster.
>>
>> postgres=> VACUUM FULL t;
>> VACUUM
>> postgres=> CLUSTER t;
>> ERROR:
On 08.12.2022 01:39, Nathan Bossart wrote:
It was also noted elsewhere [1] that the privilege requirements for CLUSTER
are not documented. The attached patch adds such documentation.
[1] https://postgr.es/m/661148f4-c7f1-dec1-2bc8-29f3bd58e242%40postgrespro.ru
Thanks for the patch. It correctl
On Wed, Dec 07, 2022 at 08:25:59PM -0600, Justin Pryzby wrote:
> Your patch makes it inconsistent with vacuum full, which is strange
> because vacuum full calls cluster.
>
> postgres=> VACUUM FULL t;
> VACUUM
> postgres=> CLUSTER t;
> ERROR: must be owner of table t
This is the existing behavior
On Wed, Dec 07, 2022 at 02:39:24PM -0800, Nathan Bossart wrote:
> Hi hackers,
>
> While looking into other opportunities for per-table permissions, I noticed
> a weird discrepancy in CLUSTER. When evaluating whether the current user
> has permission to CLUSTER a table, we ordinarily just check fo
Hi hackers,
While looking into other opportunities for per-table permissions, I noticed
a weird discrepancy in CLUSTER. When evaluating whether the current user
has permission to CLUSTER a table, we ordinarily just check for ownership.
However, the database owner is also allowed to CLUSTER all pa
22 matches
Mail list logo