[postgis-devel] Function names in PostGIS

[Paul Ramsey]

Originally we were going to have ST_ for standard functions, SE_ for
esri functions (since that's how they are defined in their API) and
SP_ for postgis-only functions.  But it seemed like it was imposing a
needless extra memorization step for users: not only do they have to
remember the mnemonic for what the function *does* ("startpoint",
"geometryn", etc) they also have to remember what category it fall
into, so they can prefix it correctly.

In the end we just want with ST_, which at least provided us the name
space uniqueness and general syntactic compatibility with
ESRI/DB2/Informix.

P.

On Mon, Jul 21, 2008 at 4:22 PM, Mark Leslie <mrk.leslie at gmail.com> wrote:
> This isn't a terrible plan, but it isn't the extent of what will need to be
> done.  When we first made the move to ST_, it was for two reasons.  SQL/MM
> had finally given us a standard namespace to grab onto.  But it was also a
> matter of isolating all the PostGIS functions from the PostgreSQL standard
> functions.  This is still something we should try and do.  If we change the
> namespaces (and I realize I'm using the term fairly loosely)  we really
> should provide namespace prefixing for the SFSQL functions, as well as the
> ESRI compatible functions, and then provide yet another for PostGIS only
> functions.  This would result in a number of redundant names, as SFSQL and
> SQL/MM have much functional overlap.
>
> --
> Mark Leslie
> Geospatial Software Architect
> LISAsoft
>
> -------------------------------------------------------------
> Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf
> 19-21 Pirrama Rd Pyrmont NSW 2009
> -------------------------------------------------------------
>
> LISAsoft is part of the A2end Group of Companies
> http://www.ardec.com.au
> http://www.lisasoft.com
> http://www.terrapages.com
>
> Obe, Regina wrote:
>>
>> I had the same thought too, but thought it would be too confusing to
>> people to go back and change all those so didn't care to voice the concern.
>>  Moving forward is a good idea I think.
>>
>> It is confusing to have things like ST_Dump() and realize it really isn't
>> an SQL/MM function.  I noticed when looking at SQL Server 2008 - that the
>> functions that are not part of the spec they did not prefix with ST.. so it
>> is easier to tell when you are using proprietary stuff.
>>
>> -----Original Message-----
>> From: postgis-devel-bounces at postgis.refractions.net
>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Håvard
>> Tveite
>> Sent: Monday, July 21, 2008 7:06 AM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Function names in PostGIS
>>
>> Regarding function names in PostGIS.
>>
>> I was wondering if it would be a good idea to reserve the
>> "ST_" prefix for SQL/MM functions?
>> This would make it easier for users to know when they are
>> using "standard" functions and when they are using (the less
>> portable) PostGIS functions.  It would also save us trouble
>> if SQL/MM should introduce new a function with the same name
>> as a PostGIS function, but with different semantics.
>>
>> Just a thought...
>>
>>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>