Hi All,



Try this....



sql bowtest << SQL_END

create table xx (a integer);

\p\g

drop permit on xx all; -- nothing to drop, but no error is raised.

\p\g

revoke all on xx from public cascade; -- there is nothing to drop, but
an error is raised.

\p\g

\q

SQL_END



It irks me that:

1. When there are no permissions to revoke, I still get an error
message.

That seems like overkill to me.



2. We can't say 'revoke all on xx;' and mean drop the lot...like drop
permit on xx ALL. We have to supply a finer level of granularity ie a
user, group etc...

That seems needlessly fussy to me.



3. drop permit is no longer documented in 9.2 or 9.3 SQL Reference
guides.

That seems suspicious to me.



Am I the only one irked by this?

Does anyone have anything to offer before I go and raise an Enhancement
Request?



Martin Bowes

DROP PERMIT is documented in the SQL guide under Appendix C: SQL
Statements from Earlier Releases of Ingres

DROP PERMIT is QUEL and not SQL, due to "history" it is still available
via SQL





From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Martin Bowes
Sent: 26 February 2010 11:44
To: Ingres and related product discussion forum
Subject: [Info-Ingres] Revoke irk



Hi All,



Try this....



sql bowtest << SQL_END

create table xx (a integer);

\p\g

drop permit on xx all; -- nothing to drop, but no error is raised.

\p\g

revoke all on xx from public cascade; -- there is nothing to drop, but
an error is raised.

\p\g

\q

SQL_END



It irks me that:

1. When there are no permissions to revoke, I still get an error
message.

That seems like overkill to me.



2. We can't say 'revoke all on xx;' and mean drop the lot...like drop
permit on xx ALL. We have to supply a finer level of granularity ie a
user, group etc...

That seems needlessly fussy to me.



3. drop permit is no longer documented in 9.2 or 9.3 SQL Reference
guides.

That seems suspicious to me.



Am I the only one irked by this?

Does anyone have anything to offer before I go and raise an Enhancement
Request?



Martin Bowes

Martin Bowes wrote:

PERMITs are a QUEL-ism so I'd assume they are deprecated, along with
INTEGRITYs.

REVOKE ALL when there are no grants to revoke is not an error so it
should not be reported as an error. That it does is not overkill, it is
a flat-out bug (a design bug or a coding bug, but a bug all the same).

I could make the same argument that dropping a non-existent table isn't
an error either, and it certainly isn't an error to the database. If
it weren't treated as an error we wouldn't need "CREATE OR RECREATE"
nor a way to test for the existence of a session global temporary
table, which are things people ask for. But given where we are and
where we've been for a long time, it's probably more usable if DROP
TABLE catches mis-typed table names. (I'd rather have had syntax like
DROP TABLE foo WITH CHECK, or something like that, to raise an error
if the table doesn't exist but it's way too late for that now.)

--
Roy

UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010
Go to http://www.iua.org.uk/join to get on the mailing list.