[postgis-devel] Proj GUCs

[Regina Obe]

> So, looking for some feedback and institutional memory here.
> 
> First, it looks like if we want to move the locus of control for the proj
grid
> cache up from the proj library into postgis proper, we will need at least
two
> and maybe all three of these GUCs.
> 
> postgis.proj_network = boolean
> postgis.proj_url_endpoint = string
> postgis.proj_grid_cache_filename = string
> 

Personally not fond of these gucs and for systems like DbaaS it would be
kinda useless.
 

> These would allow people to manipulate the behaviour of their proj
> environment without having to have system access to muck with the proj.ini
> file directly. Of course, if proj is built without curl support then these
GUCs
> will be useless.
> 
I suspect people should just know where they should muck with things is
better
And chances are people that can pmuck can muck with their proj.ini.

> Another possibility would be to just not bother with GUCs at this point
and
> make the proj configuration semi-visible via an informational function
that
> returns the these results in some form of info string:
> 
> int PROJ_DLL proj_context_is_network_enabled(PJ_CONTEXT *ctx); const
> char PROJ_DLL *proj_context_get_url_endpoint(PJ_CONTEXT *ctx); const
> char PROJ_DLL *proj_context_get_user_writable_directory(PJ_CONTEXT *ctx,
>                                                               int create);
> 
> These are all available in proj from 7.0 and up, so pretty far back.
> 
> What do you think the best approach to avoiding proj network related
issues
> is?
> 
> P
I like the informational functions a lot :)
A function that tells you where your proj data is will be a good one too
As must of my time is spent hunting figuring out where the proj data is that
postgresql is using is.