Emits PostgREST v16.0's deprecation Warning header for legacy embed target
names.
When a select aliases an embedded resource (the_tasks:tasks(...)) a
filter, order or limit may still address it by the relation name
(tasks.name=like.Code*). v16.0 kept that working under the default
url-use-legacy-target-names = true but marked it deprecated: the read plan
records the legacy match (relIsLegacyTargetNameMatch, Plan.hs), and
App.hs' toWaiResponse appends one header naming every replacement:
299 <product-token> "Embedded resource was referenced by relation name
even though it has an alias. This is deprecated and will stop working in a
future release. Update `tasks` to `the_tasks` in query string filters,
orders or limits."Two properties are reproduced here:
One header per response, from a single funnel. Upstream builds it in
toWaiResponsefrom the whole plan, so several legacy matches collapse into one header whose replacement list is comma-joined — hence aregister_before_send/2callback fed byrecord/2rather than a header set at each rendering site.It is a deprecation notice, not an error. Addressing the embed by its alias sets no flag and emits no header, and with
url-use-legacy-target-names = falsethe request is rejected outright instead of warned about (so nothing is recorded either).
299 is the RFC 7234 "miscellaneous persistent warning" code; the product
token identifies the emitting server (upstream uses PostgRESTv<version>).
Summary
Functions
Record the aliased embeds plan addressed by their relation name, so the
response carries the deprecation Warning.
Functions
@spec record(Plug.Conn.t(), map()) :: Plug.Conn.t()
Record the aliased embeds plan addressed by their relation name, so the
response carries the deprecation Warning.
The pairs are the ones Bier.Embed.resolve_target_names/2 recorded while
resolving the request's embed paths. A no-op when the request used no legacy
target name — including when url-use-legacy-target-names is off, since then
the legacy spelling is an error rather than a warning and nothing resolves.
Which is why the config is not a parameter: the gating already happened during
resolution, so there is nothing left here to gate on.