…3.47 (#9668)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

… in use after 1.0 upgrade

… output (#9673)

…lation`

…tence check

…3.56 (#9678)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

)

## Description of changes

mainly adding some composable data system slides for optional use at the
beginning. draft for now, want to review and make some more edits
potentially

also moves the slides into a directory

## Issues closed

…3.64 (#9690)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…3.70

Refactors the duckdb output to geospatial to use `* REPLACE` syntax to
generate less code when replacing a small number of geospatial columns
(usually one) among an otherwise large set of columns. Additionally, we
now only need to loop over expression columns once.

…9688)

inspired by #9535

The broken mark had the meaning of "this broke for some reason, but it
wasn't the fault of this PR, so lets ignore it for now". I find this
only meaningful in the context of that individual PR though: as soon as
the PR is merged, the usefulness drops to near 0. I come across this
mark as I'm reading code and I have no idea what action I should take.
notimpl, notyet, and never are much more useful, they signal where the
fault lies and what to do about it.

I went through and converted all the instances of broken to one of these
other 3 marks. It was fairly fast and definitely error prone. I could
see the argument for converting these all to plain xfails when we aren't
sure. I'm not sure how bad it is for these marks to be incorrect.

I tweaked the prose that describes these 3 marks. I would love your
editing of them.

Adds support for quarterly date and timestamp truncate. Closes #9714.

Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

…ng schemas (#9698)

## Description of changes

```
import ibis

ibis.options.interactive = True
ibis.options.repr.interactive.max_rows = 20

t = ibis.range(1000).unnest().name("index").as_table()
t.select(hist=t["index"].histogram(nbins=10)).value_counts()
```

```
┏━━━━━━━┳━━━━━━━━━━━━┓
┃ hist  ┃ hist_count ┃
┡━━━━━━━╇━━━━━━━━━━━━┩
│ int64 │ int64      │
├───────┼────────────┤
│     5 │        100 │
│     9 │        100 │
│     0 │        100 │
│     3 │        100 │
│     6 │        100 │
│     2 │        100 │
│     7 │        100 │
│     8 │        100 │
│     1 │        100 │
│     4 │        100 │
└───────┴────────────┘
```

## Issues closed

* Resolves #9687.

I had to make a slight change to ``histogram`` to account for an edge case that was tested for Impala. It would fail if ``nbins`` was not passed, which is a rather niche use case because ``np.histogram`` for example requires the number of bins to be passed either explicitly or implicitly. I also found a slight quirk with the current design when fixing this because if a ``base`` is passed that is not the minimum value, it would assign those out-of-bound values smaller than the base a negative bin index. It now clips those out-of-bound values to the bin index of -1 to group them together, rather than potentially having bin indices of -1 and -2 for example, so this now aligns with how ``np.histogram`` assigns a bin index of 0 for out-of-bound values.

Co-authored-by: Phillip Cloud <417981+cpcloud@users.noreply.github.com>

)

Co-authored-by: Jim Crist-Harif <jcristharif@gmail.com>

…rary aggregate function is not supported (#9731)