[postgis-devel] pg_opclass and schema awareness

[Chris Hodgson]

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