On Tue, May 25, 2021, at 22:10, Tom Lane wrote: > Magnus Hagander <mag...@hagander.net <mailto:magnus%40hagander.net>> writes: > > On Tue, May 25, 2021 at 12:55 PM Aleksander Alekseev > > <aleksan...@timescale.com <mailto:aleksander%40timescale.com>> wrote: > >> Back in 2016 while being at PostgresPro I developed the ZSON extension > >> [1]. The extension introduces the new ZSON type, which is 100% compatible > >> with JSONB but uses a shared dictionary of strings most frequently used in > >> given JSONB documents for compression. > > > If the extension is mature enough, why make it an extension in > > contrib, and not instead either enhance the existing jsonb type with > > it or make it a built-in type? > > IMO we have too d*mn many JSON types already. If we can find a way > to shoehorn this optimization into JSONB, that'd be great. Otherwise > I do not think it's worth the added user confusion.
I think the json situation is unfortunate. If carefully designing the json type from scratch, with all the accumulated experiences over the years from working with json and jsonb, I think the end result would probably be quite different. For instance, I remember Marko Tiikkaja implemented his own json type many years ago when we worked together at the same company, needing json before PostgreSQL had support for it, I remember I thought some ideas in his interface felt more natural than the built-in json type we later got. While zson improves on efficiency, there are probably lots of other improvements in the interface that could be made as well. Instead of trying to fix the existing built-in json type, I think it would be better to package the built-in functionality as a "json" extension, that would come pre-installed, similar to how "plpgsql" comes pre-installed. Users who feel they are unhappy with the entire json/jsonb types could then install "zson" or some other competing json type instead. This would allow the life-cycles of legacy/deprecated versions to overlap with future versions. Uninstallable Pre-Installed Extensions as a concept in general could perhaps be a feasible alternative to shoehorning in funtionality/optimizations in general, and also a way to avoid GUCs. The biggest downside I see is the risk for confusion among users, since there can then be multiple competing implementations providing the same functionality. It's nice to have built-ins when all users love the built-ins. /Joel
