[postgis-devel] schema aware functions

strk strk at keybit.net
Wed Jun 2 09:22:31 PDT 2004


On Tue, Jun 01, 2004 at 05:07:49PM -0400, Carl Anderson wrote:
> 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.

build_histogram2d() fixed.

> 
> 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.

It should do it already.

> 
> 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.

Added cleanup in fix_geometry_columns.

> 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.

Is it possible to extract current search_path value from withing 
a plpgsql funcion ?

--strk;

> 
> 
> 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
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list