Opened 11 years ago
Closed 8 years ago
#1393 closed task (invalid)
Evaluate use of GUC for postgis
|Reported by:||strk||Owned by:||pramsey|
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"
Change History (12)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
comment:3 by , 11 years ago
See wiki:DevGUC for a list of candidate configurations
comment:4 by , 11 years ago
|Milestone:||PostGIS 2.0.0 → PostGIS 2.1.0|
No GUCs in 2.0.0, I'm afraid.
comment:5 by , 11 years ago
|Milestone:||PostGIS 2.1.0 → PostGIS Future|
comment:6 by , 10 years ago
It looks like added SFCGAL adds the GUC postgis.backend. So, does this mean we can start using GUCs?
comment:7 by , 10 years ago
Yeap since 2.1 GUC is used for backend handling (GEOS or SFCGAL as default backend)
comment:8 by , 10 years ago
|Milestone:||PostGIS Future → PostGIS 2.1.0|
|Type:||defect → task|
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…
comment:9 by , 10 years ago
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.
comment:10 by , 10 years ago
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.
comment:11 by , 10 years ago
|Milestone:||PostGIS 2.1.0 → PostGIS 2.2.0|
looks like we've started this with sfcgal but not really tested. So punt
comment:12 by , 8 years ago
|Status:||new → closed|
This ship has sailed, we have gucs in play… proposals for specific gucs (for precision or whatnot) can have their own ticket
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).