[postgis-tickets] [PostGIS] #4674: lwgeom_cache doesn't live through not inline functions

[PostGIS]

#4674: lwgeom_cache doesn't live through not inline functions
-------------------------+---------------------------
  Reporter:  Raúl Marín  |      Owner:  pramsey
      Type:  defect      |     Status:  new
  Priority:  medium      |  Milestone:  PostGIS 3.1.0
 Component:  postgis     |    Version:  master
Resolution:              |   Keywords:
-------------------------+---------------------------

Comment (by Raúl Marín):

 I've been looking for it but I don't see any simple way to get the memory
 context of a single query.

 So let's describe the 2 options:

 * Use `flinfo->fn_mcxt`
   - Cache is done per function call.
   - Calling `Select ST_Transform(g, 3857), ST_Transform(g2, 3857) from
 table` will do 2 cache instantiations.
   - Calling the previous query 2 times inside a transaction (`BEGIN;
 query; query; END;`) will do 2 x 2 cache instantiations.
   - Doesn't work across pure SQL functions (unless inlined).


 * Use `CurTransactionContext`.
   - Cache is done per transaction.
   - Calling `Select ST_Transform(g, 3857), ST_Transform(g2, 3857) from
 table` will do only 1 instantiation.
   - Calling the previous query 2 times inside a transaction (`BEGIN;
 query; query; END;`) will create the cache only once (no matter the amount
 of times you call the query).
   - Works across "everything", as is kept alive until the end of the
 transaction.

 This second approach can be considered more dangerous in case of a leak in
 the cached objects (as things won't necessarily be deleted immediately)
 but considering that the boundaries of all the different caches are well
 established I don't expect it to be an issue.

 There is a possible "issue" related to doing a transaction with a
 ST_Transform, then a modification to spatial_ref_sys, and then another
 ST_Transform and expect it to be different (but it isn't because it is
 cached). After giving it some thought I don't consider this a problem
 since the functions are all labelled as IMMUTABLE, so I don't see a
 problem with requesting different transactions if you really want this
 kind of behaviour.

 What do you all think? If I don't hear big cries I'll clean up the patch
 (and break it apart from the changes for #4672) and push it. In any case
 I'll leave things to be easily reverted (simply change
 `CurTransactionContext` to `flinfo->fn_mcxt`).

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4674#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.