[postgis-devel] Function Naming

Obe, Regina robe.dnd at cityofboston.gov
Sat Jan 24 15:07:25 PST 2009


I don't care just toss a coin and pick one or which one has the fewest functions move to the other.

Though I would have preferred lwgeom or something like that.  postgis/pgis seems kind of tempting to use for a clueless end user.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Sat 1/24/2009 2:46 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Function Naming
 
One naming inconsistency you might have noted is that i've recommended
renaming some ugly-named gist support functions to
postgis_gist_compress, etc. But I also have some new functions for the
aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I
re-name my new pgis_ functions to use the fully spelled out
"postgis_"? I am leaning that way.

P.

On Sat, Jan 24, 2009 at 11:45 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> the geometry_* naming convention is what PgSQL uses for other
> type-support functions, which is why I recommend moving back to that
> from the ST_* versions that are currently in there.
>
> P.
>
> On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>> Paul,
>> You realize this is not a complete list.  A cursory glance looks like
>> you left out all the long transaction support functions.
>>
>> Also all those geometry_ functions you kept, I would prefer they don't
>> start with geometry.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, January 23, 2009 2:08 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Function Naming
>>
>> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt
>> You should be able to open it with any spreadsheet program that reads
>> tab-separated intput.
>> Please do a review in your abundant spare time.
>> Functions marked PUBLIC/KEEP should be part of the documentation.
>> Everything else should be invisible. We have a large collection of
>> functions that have been deprecated since 1.2. However, removing them
>> *will* break some client apps (mapserver, for example).
>> Hopefully the rest of it is self-explanatory.
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090124/ff6b263f/attachment.html>


More information about the postgis-devel mailing list