[postgis-devel] Typmod Goodness

[Chris Hodgson]

Yes, well, I was just thinking along the lines of Stephen whereby it is 
the application's responsibility to figure out which tables the user has 
access to and only list those. However, if we take one step further in 
that direction, we say why bother with the view at all, the application 
can query the system tables and figure it all out for themselves. We are 
clearly trying to go in the other direction though - the point of the 
geometry columns table in the first place was to provide a 
database-independent way for SFS-compatible applications to (a) find 
tables with geometry columns and (b) find out some basic metadata about 
a geometry column.

Given that the geometry_columns table is essentially a convenience view, 
why not make it as convenient as possible, and thus include the 
limitation by accessibility. A second view limited by your search path 
is an additional convenience that I can see being useful - however any 
existing application is only going to be looking at the 
"geometry_columns" table/view, so I think it has to include everything 
that is accessible.

So in short I think I agree with what appears to be the consensus so 
far. Of course I realize at this point we are only talking about 
geography_columns and not geometry_columns, but better to get the plan 
straight now.

Chris

Paragon Corporation wrote:
> Not so much that its sensitive -- but imagine the frustration of a user --
> they see all these wonderful tables -- they go to query them only to be 
> slapped on the wrist with a 
>
> "Denied"
>
> That's actually one of those things I liked about MySQL -- that you can only
> see databases you have access to.  In SQL Server for example if you are on a
> shared box, you have to wade through thousands of databases you can't even
> access.  Why do they bother? 
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Chris
> Hodgson
> Sent: Friday, August 07, 2009 4:03 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Typmod Goodness
>
> I'm not sure if you need the view which is limited by the search path - but
> I think limiting it to tables the user has access to makes sense.
>
> On the other hand, is there actually any sensitive data visible in the
> geo(metry|graphy)_columns table? Does it need to be limited at all?
>
> Chris
>
> Kevin Neufeld wrote:
>   
>> I'm not partial either way, but perhaps it might be an idea to follow 
>> Oracle's example:
>> http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_obj
>> relschema.htm#i1001937
>>
>>
>> Have two views. One to list the geography_columns in the user's 
>> search_path, and one to list all geography_columns which the user has 
>> select access to.
>>
>> -- Kevin
>>
>> Stephen Frost wrote:
>>     
>>> * Paragon Corporation (lr at pcorp.us) wrote:
>>>       
>>>> I disagree with the pg_table_is_visible = true addition (if it 
>>>> ensures only tables in your search path).
>>>>         
>>> So do I.  I equate 'geometry_columns' and 'geography_columns' to 
>>> 'pg_class', 'pg_tables', or 'information_schema.tables', none of 
>>> which have any such filter based on current search_path.  That's 
>>> something implemented in the client, where necessary and appropriate.
>>>
>>>     Thanks,
>>>
>>>         Stephen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>       
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>     
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>