[postgis-devel] pg_opclass and schema awareness

[strk at refractions.net]

For Chris vision Markus patch is ok, as far as it consider
USE_VERSION before attempting to call current_schema().
I suggest Markus applies his patch with that modification
in the both HEAD and 1.0 branch.
--strk;

On Tue, Apr 19, 2005 at 12:58:06PM -0700, Chris Hodgson wrote:
> I disagree. I think it is important that we allow more than one postgis 
> version to be present on the same server.
> 
> Think of a different classroom (or more importantly, workplace) scenario 
> where everyone is working on their own database applications and they 
> happen to start working with postgis at different times and so are using 
> different versions. They shouldn't each be required to run on their own 
> database server, so that they can continue working with their version of 
> postgis - that is way too much work for the server admins. They also 
> should not be required to update their applications to work with the 
> newer version of postgis just because the server admin decides to update 
> the postgis on the shared server.
> 
> I think we should leave the choice of installation up to the user - to 
> install into a specific schema, or to do a shared installation onto the 
> entire database. In fact, the two should be able to co-exists 
> peacefully, ie. Everyone has access to the public version of postgis, 
> and anyone can install their own version of postgis within their own 
> schema, and so long as their search path is setup correctly this should 
> work fine.
> 
> No-one who is running multiple versions of postgis should expect to have 
> interoperability between them - so I wouldn't worry about the 
> incompatibilities between parsers, datatypes, etc.
> 
> Just my two bits...
> Chris
> 
> >I believe that it is critical that only one PostGIS  version be 
> >allowed on a server at a time.
> >Otherwise the potentially different WKT and WKB parsers could refuse 
> >to read each others output.  Also there is no implicit cast from the 
> >my.geometry type to the your.geometry type and potentially no valid 
> >cast between the two.
> >
> >
> >WRT spatial_ref_sys and geometry_columns.  I believe that it is 
> >helpful to find these
> >through the implicit object search path and not require them to be in 
> >any particular schema.
> >
> >That way it would not be necessary to grant potentially excessive 
> >permissions to the geometry_columns table.
> >
> >I am think about a classroom setting wherein each student is directed 
> >to work within
> >a schema carrying their own userid (which would be the first component 
> >of the students search path).  Each student could have complete 
> >authority over their own parts and not
> >be able to disrupt other students work.
> >
> >
> >C.
> >
> >>Markus
> >>
> >>Markus Schaber schrieb:
> >> 
> >>
> >>>Hi, strk,
> >>>
> >>>strk at refractions.net schrieb:
> >>>
> >>>
> >>>  
> >>>
> >>>>>It should be possible having different directories, as postgresql 
> >>>>>uses
> >>>>>full qualified file names. But I have to admit that you cannot simply
> >>>>>use "make install" unmodified.
> >>>>>      
> >>>>
> >>>>Since you pointed out... actually you can ;)
> >>>>LPATH=/usr/src/postgis-modified make     
> >>>
> >>>Okay - I used a search/replace on lwpostgis.sql :-)
> >>>
> >>>Here's the proof - two different compilations of the same postgis
> >>>version in two different schemas in the same database:
> >>>
> >>>multipostgis=# select
> >>>schabi.postgis_lib_build_date(),schabi.postgis_version(),postgres.postgis_lib_build_date(),postgres.postgis_version(); 
> >>>
> >>>postgis_lib_build_date |            postgis_version            |
> >>>postgis_lib_build_date |            postgis_version
> >>>------------------------+---------------------------------------+------------------------+--------------------------------------- 
> >>>
> >>>2005-03-01 17:19:32    | 1.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 |
> >>>2005-03-01 17:22:27    | 1.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
> >>>(1 Zeile)
> >>>
> >>>But, besides the library path, I also needed to comment out the lines
> >>>640-642 of lwpostgis.sql because the subselect returned more than 
> >>>one row.
> >>>
> >>>UPDATE pg_opclass
> >>>     SET opckeytype = (select oid from pg_type where typname = 'box2d')
> >>>     WHERE opcname = 'gist_geometry_ops';
> >>>
> >>>I'm afraid that this could break the GIST indices for schema users, we
> >>>should constrain the subselect to current_schema(). The following 
> >>>should
> >>>do this:
> >>>
> >>>
> >>>UPDATE pg_opclass
> >>>   SET opckeytype = (SELECT oid FROM pg_type
> >>>                     WHERE typname = 'box2d'
> >>>                     AND typnamespace=(SELECT oid FROM pg_namespace
> >>>                                       WHERE nspname=current_schema()))
> >>>   WHERE opcname = 'gist_geometry_ops'
> >>>   AND opcnamespace = (SELECT oid from pg_namespace
> >>>                       WHERE nspname=current_schema());
> >>>
> >>>Strk, could you verify this?
> >>>
> >>>Markus
> >>>  
> >>
> >>
> >>_______________________________________________
> >>postgis-devel mailing list
> >>postgis-devel at postgis.refractions.net
> >>http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>-----------------------------------------------------
> >>This message has been scanned for viruses and
> >>dangerous content for Fulton County by DefendMail, and is
> >>believed to be clean.
> >>
> >> 
> >>
> >
> >
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel