[postgis-devel] schema aware functions

[Carl Anderson]

strk wrote:
> On Fri, May 21, 2004 at 03:07:57AM +0000, Carl Anderson wrote:
> 
>>
>>for consideration for schema aware Postgresql versions
>>
>>update geometry is a replacement
>>build_histogram2d is a new fcn (new prototype)
>>find_extent is a new fcn (new prototype)
>>
>>It works for me (TM)
>>
>>the existing functions presume that all geometry tables are accesible  
>>through the search_path.  These fcns are based on f_table_schema. 
>>f_table_name.
> 
> 
> I've committed own-grown version of the function you suggested,
> profitting to make some cleanup and shrinking of code.
> Please try current CVS and see if it still works for you :)
> 
> Note that the update_geometry_stats(table, geom) still works
> the old way (as the signature suggests).
> 
> --strk;
> 

I just downloaded CVS and update_geometry_stats has a problem.

the GUC serach_path needs to be qualified as local so that when the 
implicit transaction of the function finishes the GUC reverts to its 
original state.

try

show search_path;     (probably $user,public )
select update_geometry_stats();
show search_path;

The end result will be public,public  or myschema,public or something 
else.  In any case not the original search_path.

I also would like to more strongly ask that update_geometry_columns set 
the attrelid for invalid geoletry_columns tuples to be NULL.
I think that is proper that attrelid is set to the appropriate value
for all tuples including for the tables/columns that are bogus.

That way I can use it for house cleaning to detect the invalid tables 
and later manually check and delete the tuples for the bad tables.
Currently both this and fix_geometry_columns ignore invalid table but 
don't mark them in any way.



Looking at the problem fresh a schema aware C function histogram2d needs 
to be written.  Although this will tide us for a while.  A problem could 
stem from assuming where the function build_histogram2d exists.
ie Force it to alwas be in public or only require it to be in the 
current search_path.


Ways that I imagine PostGIS could be used

standard forms
(1) no schemas, everything in public schema
(2) installation and common tables in public, geometries in schemas

aberrant forms
(3) nothing in public, everything within schema (each schema
       has a self contained install, including geometry_columns table)
(4) installed in public schema, couple of extra installs use private
       geometry_columns dictionary in local schema


Of course assuming all the common stuff is in the public schema is easy
and pretty safe (oracle spatial, sde only allow one installation per 
database) but unless people are warned about installing common stuff in 
other places it needs to be supported



-- 
Carl Anderson
GIS Manager Fulton County, Georgia
carl.anderson at co.fulton.ga.us
404.730.8026