The ordering of endpoints and other elements seem to be lost here and there when generating the OpenAPI document. For example, even though it's specified like this:
|
content := jsonb_build_object( |
|
'application/json', |
|
oas_media_type_object( |
|
schema := oas_schema_object( |
|
type := 'array', |
|
items := oas_build_reference_to_schemas(table_name) |
|
) |
|
), |
|
'application/vnd.pgrst.object+json', |
|
oas_media_type_object( |
|
schema := oas_build_reference_to_schemas(table_name) |
|
), |
|
'application/vnd.pgrst.object+json;nulls=stripped', |
|
oas_media_type_object( |
|
schema := oas_build_reference_to_schemas(table_name) |
|
), |
|
'text/csv', |
|
oas_media_type_object( |
|
schema := oas_schema_object( |
|
type := 'string', |
|
format := 'csv' |
|
) |
|
) |
|
) |
The text/csv entry always appears as first element of the object, even though it's defined as the last. This is because:
jsonb does not preserve white space, does not preserve the order of object keys, and does not keep duplicate object keys.
Source
A solution would be to use json instead of jsonb with the drawback of losing the ability to use some operations like concatenation || that is heavily used.
The ordering of endpoints and other elements seem to be lost here and there when generating the OpenAPI document. For example, even though it's specified like this:
postgrest-openapi/sql/components.sql
Lines 544 to 567 in e0bc07c
The
text/csventry always appears as first element of the object, even though it's defined as the last. This is because:A solution would be to use
jsoninstead ofjsonbwith the drawback of losing the ability to use some operations like concatenation||that is heavily used.