[postgis-devel] Function names in PostGIS

[Håvard Tveite]

While I understand the reasons for choosing "ST_" for all
PostGIS functions, I am still in doubt that it is the best
solution.

I think the most important distinction should be between the
SQL/MM functions and the rest.  PostGIS should strongly
support SQL/MM and encourage the use of the SQL/MM functions.
In my opinion, this is best accomplished by reserving "ST_"
for the SQL/MM functions.
If there are important functions that are missing from SQL/MM
we should push for including them in future versions of the
standard.

In the current situation, it is very probable that users
would be confused by functions that have similar names and
perhaps also similar, but not identical semantics to the
SQL/MM functions.

It should not be a big problem that the non-SQL/MM functions
are more difficult to find - those few(?) that will need other
functions (PostGISSQL, SFSQL, SDESQL, SpatialWareSQL, ...)
probably have the skills to find them (Paul's suggested
prefixes would certainly help).

Making yet another radical change to function names is of
course not convenient, but I think there are significant
advantages.

Håvard

Paul Ramsey wrote:
> 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
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 

-- 
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/