Re: [HACKERS] Inconsistent syntax in GRANT - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Inconsistent syntax in GRANT
Date
Msg-id 23774.1136856968@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Inconsistent syntax in GRANT  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Inconsistent syntax in GRANT  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> At first I was just going to continue allowing table-like permissions
> for sequences if a GRANT [TABLE] was used, and add the new
> USAGE/SELECT/UPDATE capability only for GRANT SEQUENCE.  The problem was
> that you could create a non-dumpable permission setup if you added
> DELETE permission to a sequence using GRANT TABLE, and USAGE permission
> using GRANT SEQUENCE.  That couldn't be dumped with TABLE or with
> SEQUENCE, and I didn't want to do a double-dump of GRANT to fit that,
> nor did I want to throw an warning during the dump run.

Just ignore the inapplicable permissions during pg_dump.  I think you're
making this harder than it needs to be...

>     test=> REVOKE DELETE ON seq, tab FROM PUBLIC;
>     WARNING:  invalid privilege type DELETE for sequence
>     ERROR:  DELETE privilege invalid for command mixing sequences and non-sequences

This is just plain silly.  If you're going to go to that length, why not
rearrange the code to avoid the problem instead?

> Would someone look at the change in src/backend/catalog/pg_shdepend.c
> for shared dependencies?  We don't have any system catalog sequences let
> alone any shared catalog sequences, so I assume we are OK with assuming
> it is a relation.

We might have such in the future though.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposed patch to change "missing FROM" messages
Next
From: Tom Lane
Date:
Subject: Re: TODO-item: Add sleep() function, remove from regress.c