Radius search in PostgreSQL may come in employing a light and/or a much more sophisticated version. This article discusses the light one, namely the cube and the earth distance extensions, most probably sufficient for the web user’s getting here and there requirements. earth distance, depending on cube, assumes the earth to be perfectly spherical, anyone demanding a higher accuracy level, especially for the mountainous parts, may take a look at the PostGIS project.
Although radius search, the light variety, will be up fast and performing well, there may be some mantrap around, for the ones who prefer to read documentation the easy way too. First of all, PostgreSQL: Documentation: 9.1: earthdistance indicates that the point-based earth distance calculation is hard-wired to statute miles in units. You may use this circumstance to your advantage, like datachomp did in Radius Queries in Postgres, as long as you know what you’re doing. Second to that, taking on the alternate cube-based earth distance calculation, the earth_box function, accepting a lat/long and a radius on input, may return locations farther than the actual radius given (documented alike). This is because earth_box, as the name implies, still handles a box geometry on the idealized sphere (and not some higher order circle surface). But more on that below.
Flashback version query essentially enables you to lookup the incarnations of a row (defined by primary key) in the past, in a consecutive manner. Version information is depicted by a couple of pseudo-columns, namely versions_xid, versions_startscn, versions_endscn, versions_starttime, versions_endtime and versions_operation. See Using Oracle Flashback Version Query in the docs for explanations.
In combination with flashback query or flashback transaction query, one may restore a row incarnation from the past into a new table or even rollback to a past row incarnation within the same table.
This article will discuss flashback version query together with flashback query to restore one to many rows, just shown for a row of a unique key here for brevity, detailing when and when not to use timestamp and scn select where clauses to prevent pitfalls. An example table / dataset will be given, representing a real world scenario where some past data needs to be identified first and is then to be made available again.
Flashback version query uses the following pattern, including the pseudo-columns introduced above, on an actual application-, but not a system-table (alike flashback transaction query). A timestamp– or scn-range must be supplied to define the lookup window (defined by the stock of the available undo-data, remember) and to actually populate the pseudo-columns, respectively:
Getting this far, the app itself comes up and is operable as expected. Pity is but, that the folder pane does not show up when clicking the generated launcher item (though it worked in the preview mode). The launcher item itself is nothing more than some .desktop file in (~/.local/share/applications/Browser.desktop). On inspection, we have this exec entry: