[postgis-devel] PgSQL Extension Dependencies

Wed Oct 31 11:41:38 PDT 2018

Hi,

If the "features" aren't going to be versioned then it's not worth much.
We'll have the same issue, but on the level of "features" and not "package
names".

I feel that features may be useful for some specs, like "extension postgis
provides sqllmmspatialwhatever-1.1" and that means that our extension
fullfils some external paper, and if someday ESRI or Mapbox or whoever want
to do their implementation of that paper in Postgres then they will also
provide that.

ср, 31 окт. 2018 г. в 7:04, Paul Ramsey <pramsey at cleverelephant.ca>:

> 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>
> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> 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

-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181031/bb015aa6/attachment-0001.html>