Thread: BUG #6768: Failure in OBDC

BUG #6768: Failure in OBDC

From
fabio.lunkes@gmail.com
Date:
The following bug has been logged on the website:

Bug reference:      6768
Logged by:          F=C3=A1bio Hentz Lunkes
Email address:      fabio.lunkes@gmail.com
PostgreSQL version: 9.1.0
Operating system:   Windows 7
Description:=20=20=20=20=20=20=20=20

Hellow.
My teste to developer application with Microssoft Access, ODBC and Postgres.
With grant selet in one field, other fields is revoke permissions, access in
table with Microsoft Access is not possible. Failure is generate, to
permission denied. In Microsoft MS Query, no error.

Re: BUG #6768: Failure in OBDC

From
Craig Ringer
Date:
On 07/27/2012 07:52 AM, fabio.lunkes@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference:      6768
> Logged by:          Fábio Hentz Lunkes
> Email address:      fabio.lunkes@gmail.com
> PostgreSQL version: 9.1.0
> Operating system:   Windows 7
> Description:
>
> Hellow.
> My teste to developer application with Microssoft Access, ODBC and Postgres.
> With grant selet in one field, other fields is revoke permissions, access in
> table with Microsoft Access is not possible. Failure is generate, to
> permission denied. In Microsoft MS Query, no error.

I think you'll need to explain this in a bit more detail, with:

- Table definitions
- The EXACT commands you ran
- The EXACT error messages

As far as I know, running:

   GRANT SELECT on tablename(column) TO user;

shouldn't in any way restrict their existing rights, and the
documentation backs that up:

http://www.postgresql.org/docs/9.1/static/sql-grant.html

    A user may performSELECT,INSERT, etc. on a column if he holds that
    privilege for either the specific column or its whole table.
    Granting the privilege at the table level and then revoking it for
    one column will not do what you might wish: the table-level grant is
    unaffected by a column-level operation.

... so I think you might need to show what's happening in a bit more detail.

Beware that there isn't a big Microsoft Access community here.

--
Craig Ringer

Re: BUG #6768: Failure in OBDC

From
Fábio Hentz Lunkes
Date:
Sorry, all right. It was my mistake.

2012/7/27 Craig Ringer <ringerc@ringerc.id.au>
On 07/27/2012 07:52 AM, fabio.lunkes@gmail.com wrote:
The following bug has been logged on the website:

Bug reference:      6768
Logged by:          Fábio Hentz Lunkes
Email address:      fabio.lunkes@gmail.com
PostgreSQL version: 9.1.0
Operating system:   Windows 7
Description:        

Hellow.
My teste to developer application with Microssoft Access, ODBC and Postgres.
With grant selet in one field, other fields is revoke permissions, access in
table with Microsoft Access is not possible. Failure is generate, to
permission denied. In Microsoft MS Query, no error.

I think you'll need to explain this in a bit more detail, with:

- Table definitions
- The EXACT commands you ran
- The EXACT error messages

As far as I know, running:

  GRANT SELECT on tablename(column) TO user;


shouldn't in any way restrict their existing rights, and the documentation backs that up:

http://www.postgresql.org/docs/9.1/static/sql-grant.html
A user may perform SELECT, INSERT, etc. on a column if he holds that privilege for either the specific column or its whole table. Granting the privilege at the table level and then revoking it for one column will not do what you might wish: the table-level grant is unaffected by a column-level operation.
... so I think you might need to show what's happening in a bit more detail.

Beware that there isn't a big Microsoft Access community here.

--
Craig Ringer



--
    Att. Fábio Hentz Lunkes
    Cientista da Computação                       
 
Celular: 54 9178 2435
Telefone: 54 3701 2435



Re: BUG #6768: Failure in OBDC

From
Craig Ringer
Date:
On 07/31/2012 07:31 AM, Fábio Hentz Lunkes wrote:
> Sorry, all right. It was my mistake.
No worries - thanks for writing back to confirm. That way anyone else
having the issue later will have some idea where to look (or not look at
least).

--
Craig Ringer