Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of kartha02@gmail.com designates
 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=d7jpRBmVFw+KMpPX/v7Zn6irSRH0UDkH1U7WdCu4qca58vSaj+chL4qTLtFmTYs43o5PNGvqNDTB6YrhI/1am73jXIalBn4N0/hb24n8om2zvuoV+3AtaY3/tSTocb9wGI3TahMpA5Sf7sTXnpjic0aTxfc9EHwwfl3XC8zZvWw=
Message-ID: <44F7D3A8.90604@gmail.com>
Date: Thu, 31 Aug 2006 23:31:04 -0700
From: Rajesh Kartha <kartha02@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.12) Gecko/20050915
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Question on Grant/Revoke
References: <44F61C07.4020609@gmail.com>
 <d9619e4a0608310745v7a978820kd3a37e39a9ff9271@mail.gmail.com>
 <44F7108A.6030800@gmail.com> <44F71541.6080207@apache.org>
In-Reply-To: <44F71541.6080207@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:

>Rajesh Kartha wrote:
>
>  
>
>>>Mamta Satoor wrote:
>>>Manjula, I haven't looked at the SQL spec but it looks like that the
>>>      
>>>
>>update statement is doing a select operation on the
>>    
>>
>>>column id with "where id=3" and  that is what is causing Derby to send
>>>      
>>>
>>an error.
>>
>>More questions:
>>If a separate Select privilege is indeed required then I think the
>>'grant update on t1 to DBUSER' statement should not be succesful.
>>    
>>
>
>No, you need the SELECT privilege because you are reading the id column,
>not because you are updating the column.
>
>I assume if this update is executed, then no select privilege would be
>needed:
>
>UPDATE T SET ID = ?
>
>
>Or with this UPDATE
>
>UPDATE T SET ID = ? WHERE NAME = ?
>
>that one needs UPDATE on T(ID) and SELECT on T(NAME).
>
>Dan.
>
>
>
>
>
>  
>
Thanks Dan, I do see for the

UPDATE T SET ID = ? statement, the update works fine (even without the select permission, 
a bit strange though given that the user still cannot select and view  the updated data).

In the UPDATE T SET ID = ? WHERE NAME = ? case it fails because an explicit select on T was not given.

I expected an update permission would have an implicit select also on that table. In which case
the behaviour would have been consistent and both scenarios will work fine plus the user would
have been able to select and view the new data.

But if the current working is as per the SQL spec, I am fine.  Anyways, would be better to get 
this confirmed.

Rajesh