Non-C functionality

[Paul Ramsey-4]

This raises an issue of policy which our "API stable" promise makes
perhaps worth articulating: functionality should be implemented
primarily in the C library. Otherwise we're going to have this issue,
of "bugs in the SQL" which cannot be solved by a library drop-in, and
that require extra DBA attention.

If the goal of "no SQL upgrades" is paramount, then moving more code
into C makes sense.

P.

On Fri, Nov 6, 2009 at 2:41 PM, PostGIS <trac@...> wrote:

>  Okay lets punt this one.  It seems my idea of not having to change scripts
>  in minor versions that often is not working out anyway as the 1.4.1
>  already has changes in the .sql file.  I suppose we can revisit if the
>  need arises.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mark Cave-Ayland-3]

Paul Ramsey wrote:

> This raises an issue of policy which our "API stable" promise makes
> perhaps worth articulating: functionality should be implemented
> primarily in the C library. Otherwise we're going to have this issue,
> of "bugs in the SQL" which cannot be solved by a library drop-in, and
> that require extra DBA attention.
>
> If the goal of "no SQL upgrades" is paramount, then moving more code
> into C makes sense.
>
> P.

Yeah, I think we should definitely err towards C wherever possible (I
see you added some suitable LWGEOM_hasz/m in a previous commit), just
for performance reasons if nothing else.


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel