[PostGIS] #5848: expose a lower level function of TopoGeo_AddLineString that returns more info

[PostGIS]

#5848: expose a lower level function of TopoGeo_AddLineString that returns more
info
--------------------------------+---------------------------
  Reporter:  Lars Aksel Opsahl  |      Owner:  strk
      Type:  enhancement        |     Status:  new
  Priority:  medium             |  Milestone:  PostGIS 3.5.3
 Component:  topology           |    Version:  3.4.x
Resolution:                     |   Keywords:
--------------------------------+---------------------------
Comment (by Lars Aksel Opsahl):

 Replying to [comment:2 strk]:
 > The reason why those functions automatically update the TopoGeometry
 objects definition is specifically to allow you to "track" that
 information. By saving a TopoGeometry, rather than the "edge identifier"
 you will be able to query its composition and automatically find which
 edges it is composed by at any time.

 The reason why I do not TopoGeometry is performance in the resolve overlap
 and gap code.
 >
 > What you might be missing is a notification of WHEN the TopoGeometry
 object you are holding changes composition. Note that the composition of
 that object might be changed also from a different transaction than the
 one in your session.
 >

 I run single thread in different grid cell with no connecting edges so
 this should not be a problem.

 > Every now and then I think that we could be using the asynchronous
 notifications support, to let various listeners know when the definition
 of a TopoGeometry changes ( https://www.postgresql.org/docs/current/sql-
 notify.html )
 >

 Thanks, interesting, I need to checkout this for running parallel.

 > That need of being notified may serve other purposes like think triggers
 on the table holding TopoGeometry. The literal value of a TopoGeometry -
 for example: '(1,2,3,4)' - never changes, but the actual composition
 (stored in the topology relation table) can very well change and the only
 option at the moment to know when something happens is by adding user
 triggers to the relation table.
 >
 > What I'm afraid of is that even if you have a function that tells you
 what happened to the topology edges you'll still be missing some events.
 For this maybe a trigger on the relation table is even better than a
 listen/notify system.

 This will always bee an issue with database some others might change a row
 after you have updated it, that's a db locking issue. In this case have
 control on this.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5848#comment:3>
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.