[postgis-devel] PgSQL Extension Dependencies

[Paul Ramsey]

Yes, I am also a little worried that the granularity would be very hard to nail correctly such that the future doesn’t involve lots of hand-waving and redefinition of new features to paper over old definitions.

P

> On Oct 31, 2018, at 9:58 AM, Daniel Baston <dbaston at gmail.com> wrote:
> 
> It seems like we would could end up defining features at a very coarse level ("geometry", "geography", "raster"), which could be easy to get wrong, or at a very fine level ("ST_Subdivide") in which case it's not clear to me what we gain by depending on a "feature" instead of depending already-defined entities like functions or and data types.
> 
> Dan 
> 
> On Mon, Oct 29, 2018 at 4:35 PM Nicklas Avén <nicklas.aven at jordogskog.no <mailto:nicklas.aven at jordogskog.no>> wrote:
> Hi
> 
> Interesting idea!
> 
> That would mean some type of definition about what is the official features? I mean ST_DWithin would be announced, but not _ST_DWithin.
> 
> So the announced feature list would correspond to the documentation?
> 
> So ether the documentation can be dependent on this announced feature list, or we might be able to create the list from the documentation.
> 
> Have I understood the concept correct?
> 
> Or, that will not be enough with the documented features in the announced list. Since this is about dependencies to other extensions they might connect to lower levels.
> Even abi level?
> 
> Like internal functions in liblwgeom.
> 
> Is it obvious what level of features we are talking about here?
> 
> ATB
> 
> Nicklas
> 
> On Mon, 2018-10-29 at 12:36 -0700, Paul Ramsey wrote:
>> Hey all,
>>   In trying to fulfill a role as "PostGIS ambassador" to the PgSQL community, I took the opportunity to canvas developers at the EU conference last week on topics we raised during our code sprint in Boston last month. 
>>   Dmitri Fontaine, the primary author of the extension framework, was very attentive to our growing need for some kind of inter-extension dependency mechanism and potentially a versioning mechanism. 
>>   He proposed a "feature based" solution, which was almost added a few development cycles ago. (Scroll to the top of the chain to see his description of the idea.)
>> 
>> https://www.postgresql.org/message-id/flat/CA%2BTgmobe5awu4syu%3DUJJ6skRRuTpcfSGJhg7E1PemWkmGE_qOw%40mail.gmail.com#9e9066a22f8cf2a53edd92fb6c71f71c <https://www.postgresql.org/message-id/flat/CA%2BTgmobe5awu4syu%3DUJJ6skRRuTpcfSGJhg7E1PemWkmGE_qOw%40mail.gmail.com#9e9066a22f8cf2a53edd92fb6c71f71c>
>> 
>> This would allow a more granular way of extensions to describe the capabilities they offer, and for extensions to be reorganized over time. For example, right now "postgis" provides "geometry", "geography" and "raster". After 3.0, "postgis" will provide "geometry" and "geography", and "postgis_raster" will provide "raster" and require "geometry". So there is a dependency relationship between "postgis_raster" and "postgis" and the granularity of the features allows them to be moved around between extensions: a program that required "raster" would still work even after the extension re-organization, because the "raster" feature would still be there, just in a different extension.
>> 
>> The only trouble with the feature mechanism I see is that it requires omniscient developers who know exactly the right granularity to describe features with.
>> 
>> Have a look at the old patch discussion and provide your feedback and/or detailed discussion of what you think a feature/dependency/version solution that would work for us might entail.
>> 
>> Thanks!
>> P
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel <https://lists.osgeo.org/mailman/listinfo/postgis-devel>_______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/postgis-devel <https://lists.osgeo.org/mailman/listinfo/postgis-devel>_______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181031/d01f1cd1/attachment.html>