<div dir="ltr">Advantage is the distribution channels: you want some things packaged on clouds and linux repos.<div><br>In postgres world that really matters for binary, c-based, extensions - you can't get that from SQL side. Letters are just a table plus a function. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 27, 2022 at 1:15 PM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 26, 2022 at 04:22:40PM -0500, Regina Obe wrote:<br>
> Might be too big to throw into main (data wise), but as included as a<br>
> separate extension in repo would be nice.<br>
<br>
What advantage would this be compared to separate extension in<br>
separate repository as it is now ? Just wondering...<br>
<br>
I think the whole "extra" business in PostGIS was mostly done<br>
because it was hard, with SVN, to have a new repository.<br>
Nowadays OSGeo (among many others) allows users to easily setup<br>
their repositories, so why would we want to merge things togheter<br>
rather than keeping things modular ?<br>
<br>
I'd be even tempted to move address_standardizer out, as I don't<br>
think it's postgis-specific ?<br>
<br>
> I suppose it is good for testing out functions and hello world :)<br>
<br>
What advantage does it bring to testing that's not already available<br>
from geometry generation functions ?<br>
<br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>