Yes! It's mostly a limitation of how the query engine is structured. You have to make a pass over every input geometry to calculate the bounds and then another pass to calculate the Hilbert code now that the bounds are known, but that's not possible with a normal scalar function. And even if it was, because DuckDB is a streaming engine you'd have to effectively stop the query pipeline and buffer the whole queryset (potentially to/from disk) which would be pretty expensive.

If extensions could provide custom statistics we could potentially keep the known bounds around for each column, but that's not possible yet. However, I have some ideas on how to manage/track SRID/projection info for each column id like to get to in the near future, and depending on how that goes we might be able to automatically infer the bounds as the bounds of the coordinate system.

Also, there isn't really a way in SQL to pass aggregates as input to scalar functions without separating it into multiple statements (first compute the aggregate result, e.g. st_extent_agg) and then pass it to the scalar (st_hilbert). So we can't create a macro or query-rewrite-level shortcut either.

Ah, got it. That all makes a lot of sense. Could it be a mini-extension? Like is there a way with an extension to just have it run the two statements? Anyways, I'm happy to document it in the geoparquet publishing best practices I'm working on. And would be happy to contribute to the docs or a make a little tutorial. It's pretty simple, but it's not obvious at all from the info I could find.

The closes I can think of is a table macro, like this

CREATE OR REPLACE FUNCTION hilbert_auto(col_name, table_name) 
AS TABLE SELECT 
  st_hilbert(COLUMNS(col_name), (
    SELECT st_extent(ST_Extent_Agg(COLUMNS(col_name)))::BOX_2D FROM query_table(table_name))
  ) FROM query_table(table_name);

You'd use it like

SELECT * FROM hilbert_auto('geom', 't1');

This queries the table given by 'table_name' twice, once to compute the bounds and once to get the Hilbert values.

It's pretty simple, but it's not obvious at all from the info I could find.

Yeah this would for sure be good blog-post material! I want to add more guide/tutorial style content to docs at some point as well but I want to get some more stuff ready code-side before digging into that.

The hilbert_auto didn't quite work for me, as it seemed to just return a single column. I asked chatgpt and got:

SELECT *
  FROM fsq
  ORDER BY st_hilbert(
      geom,
      (
          SELECT st_extent(ST_Extent_Agg(COLUMNS(geom)))::BOX_2D
          FROM fsq
      )
  )

Which seemed to work? But only tested on ~5 million rows. Not sure if there's something wrong with that approach? It also suggested:

WITH bounds_cte AS (
  SELECT st_extent(ST_Extent_Agg(COLUMNS(geom)))::BOX_2D AS bounds
  FROM fsq
)
SELECT f.*
FROM fsq AS f
ORDER BY st_hilbert(
    f.geom,
    (SELECT bounds FROM bounds_cte)
);

which I didn't try out, and it didn't seem more readable to me.

Yeah this would for sure be good blog-post material!

Cool, I'll try to throw something up. Let me know which of the above to do, or else another way to do it with two lines of SQL.

I want to add more guide/tutorial style content to docs at some point as well but I want to get some more stuff ready code-side before digging into that.

Whenever you start this I'd be happy to try to add a few sections for some of the things I do often.