Opened 8 years ago

Closed 4 years ago

#1393 closed task (invalid)

Evaluate use of GUC for postgis

Reported by: strk Owned by: pramsey
Priority: medium Milestone: PostGIS 2.2.0
Component: postgis Version: trunk
Keywords: Cc:

Description

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

Change History (12)

comment:1 Changed 8 years ago by 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).

comment:2 Changed 8 years ago by strk

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

comment:3 Changed 8 years ago by strk

See wiki:DevGUC for a list of candidate configurations

comment:4 Changed 8 years ago by strk

Milestone: PostGIS 2.0.0PostGIS 2.1.0

No GUCs in 2.0.0, I'm afraid.

comment:5 Changed 7 years ago by robe

Milestone: PostGIS 2.1.0PostGIS Future

comment:6 Changed 6 years ago by Bborie Park

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

comment:7 Changed 6 years ago by colivier

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

comment:8 Changed 6 years ago by strk

Milestone: PostGIS FuturePostGIS 2.1.0
Type: defecttask

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 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by robe

Milestone: PostGIS 2.1.0PostGIS 2.2.0

looks like we've started this with sfcgal but not really tested. So punt

comment:12 Changed 4 years ago by pramsey

Resolution: invalid
Status: newclosed

This ship has sailed, we have gucs in play... proposals for specific gucs (for precision or whatnot) can have their own ticket

Note: See TracTickets for help on using tickets.