<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">P<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2018, at 9:58 AM, Daniel Baston <<a href="mailto:dbaston@gmail.com" class="">dbaston@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">Dan </div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Oct 29, 2018 at 4:35 PM Nicklas Avén <<a href="mailto:nicklas.aven@jordogskog.no" class="">nicklas.aven@jordogskog.no</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="">Hi</div><div class=""><br class=""></div><div class="">Interesting idea!</div><div class=""><br class=""></div><div class="">That would mean some type of definition about what is the official features? I mean ST_DWithin would be announced, but not _ST_DWithin.</div><div class=""><br class=""></div><div class="">So the announced feature list would correspond to the documentation?</div><div class=""><br class=""></div><div class="">So ether the documentation can be dependent on this announced feature list, or we might be able to create the list from the documentation.</div><div class=""><br class=""></div><div class="">Have I understood the concept correct?</div><div class=""><br class=""></div><div class="">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.</div><div class="">Even abi level?</div><div class=""><br class=""></div><div class="">Like internal functions in liblwgeom.</div><div class=""><br class=""></div><div class="">Is it obvious what level of features we are talking about here?</div><div class=""><br class=""></div><div class="">ATB</div><div class=""><br class=""></div><div class="">Nicklas</div><div class=""><br class=""></div><div class="">On Mon, 2018-10-29 at 12:36 -0700, Paul Ramsey wrote:</div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hey all,<div class=""> 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. </div><div class=""> 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. </div><div class=""> 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.)</div><div class=""><br class=""></div><div class=""><a href="https://www.postgresql.org/message-id/flat/CA%2BTgmobe5awu4syu%3DUJJ6skRRuTpcfSGJhg7E1PemWkmGE_qOw%40mail.gmail.com#9e9066a22f8cf2a53edd92fb6c71f71c" target="_blank" class="">https://www.postgresql.org/message-id/flat/CA%2BTgmobe5awu4syu%3DUJJ6skRRuTpcfSGJhg7E1PemWkmGE_qOw%40mail.gmail.com#9e9066a22f8cf2a53edd92fb6c71f71c</a><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks!<br class="">P</div></div></div>
<pre class="">_______________________________________________
postgis-devel mailing list
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" class="">postgis-devel@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" target="_blank" class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></pre></blockquote></div>_______________________________________________<br class="">
postgis-devel mailing list<br class="">
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" class="">postgis-devel@lists.osgeo.org</a><br class="">
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank" class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>
_______________________________________________<br class="">postgis-devel mailing list<br class=""><a href="mailto:postgis-devel@lists.osgeo.org" class="">postgis-devel@lists.osgeo.org</a><br class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</div></blockquote></div><br class=""></div></body></html>