| 616 | | == '''Why avoid to link with PostGIS?''' == |
| 617 | | |
| 618 | | The general idea is that when we need PostGIS services to manipulate geometries, we should always use PL/pgSQL functions instead of implementing them in C. This prevent us from having to link with any PostGIS lib (mostly liblwgeom.a). This has some advantages: |
| 619 | | |
| 620 | | 1. We facilitate backward compatibility with older version of PostGIS - The SQL API is much more stable than the internal C API. |
| | 616 | == '''Why is it importnat to avoid linking with PostGIS?''' == |
| | 617 | |
| | 618 | There is three level of dependency over PostGIS: |
| | 619 | |
| | 620 | 1) Compilation dependency. This is only a problem as far as we have to first compile PostGIS in order to compile WKT Raster. This remains our problem, not a user problem. |
| | 621 | |
| | 622 | 2) Linking dependency. This is the major problem since it prevent us from releasing when we want as we always have to link with the last release of PostGIS and that this might brake support for older PostGIS. WKT Raster independency over PostGIS means WKT Raster can be installed over (almost) every version of PostGIS past and future (as far as their SQL API do not change and it (should) change less often than the C API). This give us much more flexibility (we can release when we want/need) and to our users (they can install over any version of PostGIS i.e. They don<t change their installation. We take for granted that WKT Raster users are already experienced PostGIS users). It means that even if they have a fairly old version of PostGIS installed on their system, they can install the very last WKT Raster. It also means that they can keep their version of WKT Raster even if they upgrade PostGIS. We can not take for granted that PostGIS folks will integrate WKT Raster into the main PostGIS trunk soon and fix this problem. There might be years before WKT Raster is officially integrated in PostGIS releases. Some functions still link with PostGIS and this does not seems to prevent WKT Raster to work with many versions of PostGIS. This is to be tested. |
| | 623 | |
| | 624 | 3) SQL Dependency. WKT Raster is very much dependent on PostGIS at the SQL level and it will remains like this. Most (every) WKT Raster functions handling geometries rely on PostGIS SQL functions. This does not prevent WKT Raster to work with past/future versions of PostGIS as far as the SQL API does not change, and it is not in the POSTGIS folks interest to change it too much so it should remain very stable. |
| | 625 | |
| | 626 | So the general idea is: When we need PostGIS services to manipulate geometries, we should always use PL/pgSQL functions instead of implementing them in C. This prevent us from having to link with any PostGIS lib (mostly liblwgeom.a). This has the following advantages: |
| | 627 | |
| | 628 | 1. We facilitate backward and forward compatibility with older and newer versions of PostGIS - The SQL API is much more stable than the internal C API. |
