Evaluate use of GUC for postgis

[strk]

Hooking on the Grand Unified Configuration of PostgreSQL would give us a few interesting advantages. Ticket #267 is an example of that, which in turn refers to other (unlinked) cases in which the need arised (arose?).

This ticket is here to stay. We'll see later if it's to be moved to 2.1 or Future as a milestone.

For now what I can tell after a brief research is that GUC is available in 8.4 and up to 9.1 requires an edit in postgresql.conf to allow SET syntax for "postgis.vars"

 http://www.postgresql.org/docs/8.3/static/runtime-config-custom.html

[strk]

Note that the need to modify postgresql.conf would require the testing framework to create its own database cluster for the sake of having a controlled configuration. The same is true for avoiding localized messages or other things controllable by config (like default schema name).

[strk]

Some tickets which would benefit from GUC handling: #267 about geography, #287 about ST_AsText standard, #288 about ST_AsBinary standard

[strk]

See wiki:DevGUC for a list of candidate configurations

[strk]

No GUCs in 2.0.0, I'm afraid.

[dustymugs]

It looks like added SFCGAL adds the GUC postgis.backend. So, does this mean we can start using GUCs?

[colivier]

Yeap since 2.1 GUC is used for backend handling (GEOS or SFCGAL as default backend)

[strk]

I guess the SFCGAL use makes a perfect mean to "evaluate". For example, how about starting with creating our own cluster at "make check" time ? We'll need it for enabling the GUC, right ? Also we'd need run_test to allow passing an init file or strings to set any GUC we want during a specific run, in that we'll need to make sure GUC values are in the way we want them to...

[robe]

FWIW: The bots already do that. They always start with a new cluster. Eventually I think we'd want to setup two sets of regress tests one without SFCGAL and one with.

[colivier]

We already check postgis.backend setting in regress/regress_sfcgal, with SET.

I'm not that convince we have also to deal with fresh cluster and postgresql.conf. It could be painfull to maintain and we have to trust PostgreSQL itself at a point.