<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] Function Naming</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>On second thought existing support functions use postgis_ such as postgis_full_version()<BR>
<BR>
so I guess postgis would be better than pgis. But its a bit annoying to me that we've got functions intended to be used by end users mixed in with functions that aren't.<BR>
<BR>
I actually like the whole underscore bit even though I suppose it doesn't follow postgresql convention.<BR>
<BR>
So those new functions you have would be<BR>
<BR>
_postgis_geometry_accum_finalfn<BR>
<BR>
Same goes with all those geometry_ I whined about.<BR>
<BR>
Seems better to be<BR>
<BR>
_geometry_<BR>
<BR>
Since their public exposure is as operators or helper functions to operators. Not to be used directly by end users.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Obe, Regina<BR>
Sent: Sat 1/24/2009 6:07 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: RE: [postgis-devel] Function Naming<BR>
<BR>
I don't care just toss a coin and pick one or which one has the fewest functions move to the other.<BR>
<BR>
Though I would have preferred lwgeom or something like that. postgis/pgis seems kind of tempting to use for a clueless end user.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>
Sent: Sat 1/24/2009 2:46 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Function Naming<BR>
<BR>
One naming inconsistency you might have noted is that i've recommended<BR>
renaming some ugly-named gist support functions to<BR>
postgis_gist_compress, etc. But I also have some new functions for the<BR>
aggregates, named like pgis_geometry_accum_finalfn(pgis_abs). Should I<BR>
re-name my new pgis_ functions to use the fully spelled out<BR>
"postgis_"? I am leaning that way.<BR>
<BR>
P.<BR>
<BR>
On Sat, Jan 24, 2009 at 11:45 AM, Paul Ramsey <pramsey@opengeo.org> wrote:<BR>
> the geometry_* naming convention is what PgSQL uses for other<BR>
> type-support functions, which is why I recommend moving back to that<BR>
> from the ST_* versions that are currently in there.<BR>
><BR>
> P.<BR>
><BR>
> On Fri, Jan 23, 2009 at 11:31 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>
>> Paul,<BR>
>> You realize this is not a complete list. A cursory glance looks like<BR>
>> you left out all the long transaction support functions.<BR>
>><BR>
>> Also all those geometry_ functions you kept, I would prefer they don't<BR>
>> start with geometry.<BR>
>><BR>
>> -----Original Message-----<BR>
>> From: postgis-devel-bounces@postgis.refractions.net<BR>
>> [<A HREF="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of Paul<BR>
>> Ramsey<BR>
>> Sent: Friday, January 23, 2009 2:08 PM<BR>
>> To: PostGIS Development Discussion<BR>
>> Subject: [postgis-devel] Function Naming<BR>
>><BR>
>> I've placed my review in SVN here: docs/rfc/postgis_rfc_03_sheet.txt<BR>
>> You should be able to open it with any spreadsheet program that reads<BR>
>> tab-separated intput.<BR>
>> Please do a review in your abundant spare time.<BR>
>> Functions marked PUBLIC/KEEP should be part of the documentation.<BR>
>> Everything else should be invisible. We have a large collection of<BR>
>> functions that have been deprecated since 1.2. However, removing them<BR>
>> *will* break some client apps (mapserver, for example).<BR>
>> Hopefully the rest of it is self-explanatory.<BR>
>> P.<BR>
>> _______________________________________________<BR>
>> postgis-devel mailing list<BR>
>> postgis-devel@postgis.refractions.net<BR>
>> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
>> -----------------------------------------<BR>
>> The substance of this message, including any attachments, may be<BR>
>> confidential, legally privileged and/or exempt from disclosure<BR>
>> pursuant to Massachusetts law. It is intended<BR>
>> solely for the addressee. If you received this in error, please<BR>
>> contact the sender and delete the material from any computer.<BR>
>> _______________________________________________<BR>
>> postgis-devel mailing list<BR>
>> postgis-devel@postgis.refractions.net<BR>
>> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
>><BR>
><BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>