Replace the single-column `<fk table='...' column='...'/>` marker with a
unified, composite-capable format `<fk table='...' columns='local:foreign,...'/>`
and emit full column lists for many-to-many markers, so clients can
reconstruct composite relationships.
- Match every real table relationship a column participates in, instead of
only single-column foreign keys, still preferring tables over the
view-derived relationships.
- Emit the full ordered local->foreign column mapping in the `<fk>` marker
and the full source/target column lists in the `<m2m>` marker.
- Add composite foreign key and composite m2m fixtures plus OpenAPI spec
assertions.
Add unique constraint and many-to-many relationship metadata to the
generated OpenAPI spec so clients can render them.
- Store unique constraints on Table as tableUniqueCols (mirroring
tablePKCols) instead of denormalizing them onto each Column.
- Compute unique constraints via a per-table tbl_unique_cols CTE in
tablesSqlQuery.
- Annotate unique columns and composite unique constraints in property
descriptions, and emit m2m markers in table descriptions.
Disabling the autovacuum daemon should also help reproducibility in
theory, although I don't know of any cases where we hit a problem with
that.
VACUUM changes the order of rows that PostgreSQL returns for some table
without explicit ordering, thus doing the latter to make it consistently
reproducible.
After ANALYZE estimates are 100% exact for the moment, so some requests
which returned 206 Partial Response now return 200 instead. The fact
that PostgREST returns 206 on an unfiltered endpoint can probably be
considered a bug.
PostgREST failed when querying role settings where current
role name contained uppercase letters. This commit resolves
it by quoting the CURRENT_USER.
Signed-off-by: Taimoor Zaeem <taimoorzaeem@gmail.com>
The hasSingleUnnamedParam function was only checking the parameter type
but not whether the parameter actually had no name. This caused functions
with a single NAMED parameter (e.g., `foo(data json)`) to incorrectly
match the single-param fallback mode.
The result was a confusing PostgreSQL error 42883 "function does not exist"
instead of a clean PGRST202 error explaining that no matching function
was found.
Added ppName == mempty check so functions with named parameters don't
incorrectly match the single-param fallback.
- Fixed "column reference <col> is ambiguous" error when selecting "?select=...table(col,count())"
- Fixed "column <json_aggregate>.<alias> does not exist" error when selecting "?select=...table(aias:count())"
Previously using a generic mimetype handler failed when any kind of select= was given, because
we tried to cast the select-result to the original table type. With this change, this cast is
only applied when select=* is given implicitly or explicitly. This is the only case where this
makes sense, because this guarantees that correct columns are selected in the correct order for
this cast to succeed.
Resolves#3160
jimmy
steve-chavez