[postgis-devel] PgSQL Extension Dependencies

[Daniel Baston]

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>
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
>
> 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 listpostgis-devel at lists.osgeo.orghttps://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/2f2bce7d/attachment-0001.html>