Is this extension documented? What is the precise behavior? Are there guarantees that it will be preserved throughout future versions of SQLite? When was it introduced?
Repeating myself so we don't lose focus: I was originally looking at the inconsistent definition of open/closed branches. Given what you say about GROUP BY, the "new" definition of a closed branch is a branch whose most recent leaf is referenced by a closed tag, whereas the classical definition (used by the branch ls command and the original /brlist page) is a branch whose leaves are all referenced by closed tags. In both cases, all branches having the same name are considered to be a single branch. Going forward, which definition do we want? On Nov 19, 2016 06:32, "Richard Hipp" <d...@sqlite.org> wrote: > On 11/19/16, Andy Goth <andrew.m.g...@gmail.com> wrote: > > > > If I understand correctly, the baseline branch ls query defines a closed > > branch as having no leaves not referenced by closed tags. The baseline > > "new" /brlist query instead checks whether "the" check-in is referenced > > by a closed tag. Which check-in? Hard to say. GROUP BY doesn't define > > which row is used to evaluate the result expressions. > > True enough for standard SQL. But SQLite is extended so that the > result set evaluation is for the row where max(event.mtime) is > maximized. So, it is looking at the most recent leaf of the branch. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > fossil-dev mailing list > fossil-dev@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev >
_______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
