[Info-ingres] Behaviour change on schema.table_name

[Martin Bowes]

I'm coming around to your view here Karl.

The user who reported this is very trusted and they showed me that there code has not changed since before the start of the year. We switched to 11.0 in November 2018. The application has been dormant for an extended period of time and has only recently been resurrected. 

We started a pre license manager version of 10.2 and an opensource 10.1 just to see if we could develop a demonstration of the problem and have been completely unable to do so.

I'm considering the possibility that some rogue tables/views owned by the user or the database owner existed in the 10.2 version of the database at that time which allowed his queries to 'work'.

Marty 

-----Original Message-----
From: Karl and Betty Schendel [mailto:schendel at kbcomputer.com] 
Sent: 27 August 2019 11:30
To: Martin Bowes
Cc: info-ingres at lists.planetingres.org
Subject: Re: [Info-ingres] Behaviour change on schema.table_name

On Aug 27, 2019, at 5:47 AM, Martin Bowes <martin.bowes at ndph.ox.ac.uk> wrote:
> 
> Eg. In database ddd owned by user downer, a user u1 has a table t1 on which they have granted group g1 select access.
>  
> Another user (u2) connects to the database specifying the –Gg1 connection attribute.
>  
> They select * from t1;
>  
> In 10.1 and 10.2 the user would get data from u1.t1
>  
> In 11.1 the query fails with E_US0845 Table 't1' does not exist or is not owned by you.

This is real close to "I don't believe it" territory.  Group membership has zero
implication for the schema search path, and in fact the parser in general
has no idea what group the session is running in.

If that's how it worked in 10.x, I bet it was purely by accident.  (I can't
look at the code right this moment to see.)

Karl