Files
zeekay 9a90943b8f merge: ClickHouse 26.7.1.1315-stable into datastore — preserve debrand
13,838 upstream commits, forward from the 26.6.1.1 fork point. 129 conflicts:
37 resolved mechanically (take upstream's file, re-apply the brand sweep) and
92 by hand where our fork and upstream had both changed the same code.

The rule throughout: upstream owns the engine, we own the naming and a small set
of deliberate deviations. Never resolve by discarding an upstream change — a
dropped rename or a missed new parameter becomes a compile error a thousand
files away.

Deviations verified intact after the merge:
  ENABLE_XRAY still defaults OFF        (CMakeLists.txt:105)
  X-Datastore-User read by the server   (authenticateUserByHTTP.cpp)
  X-ClickHouse-* in src/                0
  hanzo/research                        present
  system.*_log retention bound          present
  ArrowFlight rip                       held against upstream re-adding it

Two things worth naming, because neither shows up as a conflict:

  src/CMakeLists.txt gained an UNGUARDED
  `add_object_library(datastore_storages_arrowflight Storages/ArrowFlight)` from
  upstream, for a directory our gRPC rip deleted. It sat outside every conflict
  hunk, so a resolver reading only the markers would sail straight past it into
  a CMake configure error. Removed; the Server/ArrowFlight sibling at line 474
  stays because it is inside `if (TARGET ch_contrib::arrow_flight)`.

  The brand sweep had rewritten github.com/ClickHouse/ClickHouse issue links to
  github.com/Datastore/Datastore — a dead host. Those point at upstream's own
  tracker and are restored, alongside the contributors list, sql.clickhouse.com
  and the ClickHouse Inc copyright: attribution is theirs, not ours to rename.

base/glibc-compatibility/memcpy/memcpy.h is deleted, not kept: upstream dropped
it for LLVM-libc's, and our only change to it was a comment rebrand.
2026-07-26 14:47:43 -07:00
..
2026-06-16 21:32:49 +00:00
2026-02-09 18:21:32 +01:00
…
…

alt text

Travis Build Status Build status CII Best Practices

POCO (Portable Components) C++ Libraries are:

  • A collection of C++ class libraries, conceptually similar to the Java Class Library, the .NET Framework or Apple's Cocoa.
  • Focused on solutions to frequently-encountered practical problems.
  • Focused on 'internet-age' network-centric applications.
  • Written in efficient, modern, 100% ANSI/ISO Standard C++.
  • Based on and complementing the C++ Standard Library/STL.
  • Highly portable and available on many different platforms, from embedded to server.
  • Open Source, licensed under the Boost Software License.

alt text


To start using POCO, see the Guided Tour and Getting Started documents.


POCO has an active user and contributing community, please visit our web site and blog. Answers to POCO-related questions can also be found on Stack Overflow.

Please see CONTRIBUTING for submitting contributions, bugs reports, feature requests or security issues.


In regards to Boost, in spite of some functional overlapping, POCO is best thought of as a Boost complement (rather than replacement). Side-by-side use of Boost and POCO is a very common occurrence.