Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Statistics that live in your SQL

kolistat.com

Post reply on HN
Print view View original

1–10 of 23 posts

Re: Statistics that live in your SQL

#3

Post by caerbannogwhite »

williamcotton wrote: post #2

The plotting aspect of this seems very similar to: https://opensource.posit.co/blog/2026-04-20_ggsql_alpha_rele...

That's exactly the inspiration! I made a post here on HN about that a few weeks ago: https://news.ycombinator.com/item?id=48108815

My plan is to release a blog post about all VISUALIZE current features next week, explicitly mentioning Posit's alpha GGPLOT.

/edit: clarifications

Re: Statistics that live in your SQL

#4

Post by thomasp85 »

caerbannogwhite wrote: post #3
williamcotton wrote: post #2

The plotting aspect of this seems very similar to: https://opensource.posit.co/blog/2026-04-20_ggsql_alpha_rele...

That's exactly the inspiration! I made a post here on HN about that a few weeks ago: https://news.ycombinator.com/item?id=48108815 My plan is to release a blog post about all VISUALIZE current features next week, explicitly mentioning Posit's alpha GGPLOT. /edit: clarifications

ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path)

I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have

Re: Statistics that live in your SQL

#5

Post by geysersam »

Looks great!

One minor correction - the `summarize` function in duckdb can also be used in CTEs etc.

But you have to wrap the `summarize` in a `from` clause like this:

  with
    some_table as (from range(10)),
    x as (from (summarize some_table))
  from x;

Re: Statistics that live in your SQL

#6

Post by caerbannogwhite »

thomasp85 wrote: post #4
caerbannogwhite wrote: post #3

Earlier quoted context omitted.

That's exactly the inspiration! I made a post here on HN about that a few weeks ago: https://news.ycombinator.com/item?id=48108815 My plan is to release a blog post about all VISUALIZE current features next week, explicitly mentioning Posit's alpha GGPLOT. /edit: clarifications

ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path) I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have

First of all, nice to meet you! The honest answer is timing: the first VISUALIZE commit on my side was april 25th; ggsql-duckdb's first commit was April 23rd. So I genuinely didn't know it existed!

About the name: yours is the official Posit one, and you were there first, so I'll rename my branding; there should be one ggsql, and it's yours. Mine only exposes VISUALIZE as the keyword anyway.

The actual name of the extension is the-stats-duck, which runs inside duckdb-wasm (it powers an in-browser data tool) and emits a Vega-Lite spec inline for the host to render. Your implementation (which I think is Rust based and an in-process HTTP server that opens a browser), is a native pattern, but correct me if I'm wrong! mine is deliberately thin and wasm-safe, not a whole engine.

About the parity, you're right, and I'm not chasing it; for real grammar-of-graphics, ggsql should be the tool! but, if that's ok with you, I'd love to keep the syntax aligned!

Re: Statistics that live in your SQL

#7

Post by caerbannogwhite »

geysersam wrote: post #5

Looks great! One minor correction - the `summarize` function in duckdb can also be used in CTEs etc. But you have to wrap the `summarize` in a `from` clause like this: with some_table as (from range(10)), x as (from (summarize some_table)) from x;

Thank you! I'll add note about it

Re: Statistics that live in your SQL

#9

Post by caerbannogwhite »

PashaGo wrote: post #8

Interesting, but I think it works only for quick ad-hoc analysis. For dashboards or deeper research, you still need other tools

Yes, that's exactly its main purpose! I initially started because I needed a dataset browser. I work with clinical trials, so we usually get raw data files in all possible formats, from CSV to EXCEL and, of course, SAS formats. But since I was already using DuckDB, I thought about extending it a bit further, so you can quickly get a glance at the data.

Re: Statistics that live in your SQL

#10

Post by thomasp85 »

caerbannogwhite wrote: post #6
thomasp85 wrote: post #4

Earlier quoted context omitted.

ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path) I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have

First of all, nice to meet you! The honest answer is timing: the first VISUALIZE commit on my side was april 25th; ggsql-duckdb's first commit was April 23rd. So I genuinely didn't know it existed! About the name: yours is the official Posit one, and you were there first, so I'll rename my branding; there should be one ggsql, and it's yours. Mine only exposes VISUALIZE as the keyword anyway. The actual name of the ex…

No objections at all. But probably good to describe that it is ggsql-inspired rather than a full reimplementation as it could lead to user confusion about what syntax is supported etc

And you are correct about how our extension is implemented and it isn’t currently wasm ready

Post reply on HN