There is nothing intrinsically postgis about the solution, we envisage it a
JDBC capability.
A parameter with a sensible default could advertise the table or function
that would be interrogated to find functions intended to be advertised.
My could attempt to call a function
getRegisteredFunctions(key) where key is a configuration parameter that may
be null. Such a function could just hardcode function names if you only want
a couple.
The alternative would be to allow the JDBC connection to access a table, so
different user logins could access different sets of functions. This may be
more work at the db administration end.
Open to ideas as to which is best strategy.
Rob
On Tue, Jul 22, 2008 at 12:29 AM, Jody Garnett <[EMAIL PROTECTED]>
wrote:
> A couple things; executing any sql function is not a good thing from a
> security standpoint (but you know this). You should be able to advertise
> additional functions on a data store by datastore basis using the filter
> capabilities data structure. You are the first person to want to do this
> so please let me know if you have any questions.
>
> I like your idea of storing the additional functions as a table; the
> best move would be to have the PostGISDataStoreFactory check for this
> table and make the correct implementations as needed.
>
> Jody
>
> Ben Caradoc-Davies wrote:
> > I have written a prototype for "registered function" support in WFS
> > filter queries, in which functions not implemented in GeoServer are
> > passed to the database for execution. This allows complex or expensive
> > domain-specific queries to be performed on the database server side.
> >
> > Please comment if you think that this could be expanded or modified to
> > help you.
> >
> > See:
> > http://jira.codehaus.org/browse/GEOT-1929
> >
> > Notes:
> > - Only PostGIS is supported at the moment.
> > - Only the community-schemas build has it
> > - There is no register of functions, so all are permitted (SECURITY!)
> > (See GEOT-1930.)
> >
> > More and better support when this is merged onto trunk and into core.
> >
> > Credits go to Rob Atkinson for the concept, name, and advocating this
> > approach to users for about a year. :-)
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
