Add Support for Python 3.14 (#437)

Add support for Python 3.14 (released in October 2025). Adds testing for
3.14 as well as updating allowed Python versions.

Add Support for Python 3.13 (#436)

Python 3.13 has been out for a while and we'd like to be able to support
running on it. Adds testing for 3.13 (and 3.12) as well as updating
allowed Python versions and the Dockerfile.

Tests updated as well.

---------

Co-authored-by: Mindaugas Rukas <3825716+mindaugasrukas@users.noreply.github.com>

Handle object with missing properties in JSON schema (#434)

# Summary

Small change to the `JSONSchemaConverter` to handle objects with no
"properties" keyword, which is technically valid

```json
{
    "type": "object"
}
```

The output is the same as an object with `"properties": {}` - a
`StructType` with an empty fields array

Co-authored-by: Adrian Kreuziger <adrian@gable.ai>

Improve handling of single item type arrays in JSON schema (#433)

# Summary

Small change to the `JSONSchemaConverter` to better handle `"type"`
defined as a single element array (`{"type": ["string"]}`). This has two
effects:

* Directly return the type in the array instead of a single type union,
which was technically correct but annoying
* Handle edge case where `type` is a single element array, and the
object contains additional properties specific to that type:
    ```
    {
        "type": ["array"], 
        "items": { "type": ["string"] }
    }
    ```
The [JSON schema
spec](https://json-schema.org/understanding-json-schema/reference/type#type-specific-keywords)
is kind of ambiguous here as it only covers the case where the array has
more than one value
> An array of strings. When type is used as an array, it contains more
than one string specifying the types mentioned above. In this case, the
instance data is valid if it matches any of the given types.
   
but the JSON schema validator I tried & the one used by the tests both
say it's valid 🤷

Co-authored-by: Adrian Kreuziger <adrian@gable.ai>

Detect unsigned integers in MySQL converter (#431)

Adds support for unsigned integer values to the MySQL converter

> UNSIGNED, if specified, disallows negative values. The UNSIGNED
attribute is deprecated for columns of type
[FLOAT](https://dev.mysql.com/doc/refman/8.4/en/floating-point-types.html)
(and any synonyms) and you should expect support for it to be removed in
a future version of MySQL. Consider using a simple CHECK constraint
instead for such columns.

https://dev.mysql.com/doc/refman/8.4/en/numeric-type-syntax.html

Bump to 0.12.0

Drop version to 0.11.0

Support postgresql enums

## Support postgresql enums

Adds support for postgresql enums, addressing
#415.

This uses the
[pg_type](https://www.postgresql.org/docs/current/catalog-pg-type.html)
and
[pg_enum](https://www.postgresql.org/docs/current/catalog-pg-enum.html)
tables to discover the valid enum values for any columns using

## Limitations

There are other [postgresql custom
types](https://www.postgresql.org/docs/current/sql-createtype.html) that
I am not attempting to support in this PR:

* composite type
* a range type
* a base type
* a shell type


## Validation

Using the enum example in the [postgres
docs](https://www.postgresql.org/docs/current/datatype-enum.html), the
integration test creates a new custom enum type, uses it in the test
table, and expects the recap `EnumType` to be found.

I also added a unit test for basically the same thing.

Bump to 0.10.0

Support PG array dimensionality

Add array support to postgres reader/converter with dimensionality read
from `pg_attribute.attndims`. This is grabbed by joining on
`information_schema.columns.column_name = pg_attribute.attname`

This a followup to #410 which
lays a tiny bit of groundwork for
#264 (comment)