v0.40.0

performance improvements, bug fixes, backwards incompatible variable

handling changes

• OIDC login redirects now use HTTP 303 responses so POST submissions are converted to safe GET requests before reaching the identity provider, fixing incorrect reuse of the original POST (HTTP 307) that could break standard auth flows.
• SQLPage now respects HTTP accept headers for JSON. You can now easily process the contents of any existing sql page programmatically with:
  • curl -H "Accept: application/json" http://example.com/page.sql: returns a json array
  • curl -H "Accept: application/x-ndjson" http://example.com/page.sql: returns one json object per line.
• Fixed a bug in sqlpage.link: a link with no path (link to the current page) and no url parameter now works as expected. It used to keep the existing url parameters instead of removing them. sqlpage.link('', '{}') now returns '?' instead of the empty string.
• sqlpage.fetch(null) and sqlpage.fetch_with_meta(null) now return null instead of throwing an error.
• New Function: sqlpage.set_variable(name, value)
  • Returns a URL with the specified variable set to the given value, preserving other existing variables.
  • This is a shorthand for sqlpage.link(sqlpage.path(), json_patch(sqlpage.variables('get'), json_object(name, value))).
• Variable System Improvements: URL and POST parameters are now immutable, preventing accidental modification. User-defined variables created with SET remain mutable.
  • BREAKING: $variable no longer accesses POST parameters. Use :variable instead.
    • What changed: Previously, $x would return a POST parameter value if no GET parameter named x existed.
    • Fix: Replace $x with :x when you need to access form field values.
    • Example: Change SELECT $username to SELECT :username when reading form submissions.
  • BREAKING: SET $name no longer makes GET (URL) parameters inaccessible when a URL parameter with the same name exists.
    • What changed: SET $name = 'value' would previously overwrite the URL parameter $name. Now it creates an independent SET variable that shadows the URL parameter.
    • Fix: This is generally the desired behavior. If you need to access the original URL parameter after setting a variable with the same name, extract it from the JSON returned by sqlpage.variables('get').
    • Example: If your URL is page.sql?name=john, and you do SET $name = 'modified', then:
      • $name will be 'modified' (the SET variable)
      • The original URL parameter is still preserved and accessible:
        • sqlpage.variables('get')->>'name' returns 'john'
  • New behavior: Variable lookup now follows this precedence:
    • $variable checks SET variables first, then URL parameters
    • SET variables always shadow URL/POST parameters with the same name
  • New sqlpage.variables() filters:
    • sqlpage.variables('get') returns only URL parameters as JSON
    • sqlpage.variables('post') returns only POST parameters as JSON
    • sqlpage.variables('set') returns only user-defined SET variables as JSON
    • sqlpage.variables() returns all variables merged together, with SET variables taking precedence
  • Deprecation warnings: Using $var when both a URL parameter and POST parameter exist with the same name now shows a warning. In a future version, you'll need to explicitly choose between $var (URL) and :var (POST).
• Improved performance of sqlpage.run_sql.
  • On a simple test that just runs 4 run_sql calls, the new version is about 2.7x faster (15,708 req/s vs 5,782 req/s) with lower latency (0.637 ms vs 1.730 ms per request).
• add support for postgres range types