fix: emit warning for legacy target names

[steve-chavez]

Reverts #4104 and eases transition towards the breaking change.

When the request with the deprecated syntax comes we log a warning, like so:

$ PGRST_LOG_LEVEL=info postgrest-with-pg-14 -f test/spec/fixtures/load.sql postgrest-run

$ curl 'localhost:3000/projects?id=eq.1&select=id,name,the_tasks:tasks(id,name),clientes:clients(*)&tasks.order=name.asc&clients.id=eq.1'

08/May/2026:21:10:24 -0500: WARNING: Embedded resource was referenced by relation name even though it has an alias. This is deprecated and will stop working in a future release.
08/May/2026:21:10:24 -0500: Please update the filters that use `tasks` to `the_tasks`, `clients` to `clientes` in `GET /projects?id=eq.1&select=id,name,the_tasks:tasks(id,name),clientes:client
s(*)&tasks.order=name.asc&clients.id=eq.1`
127.0.0.1 - postgrest_test_anonymous [08/May/2026:21:10:24 -0500] "GET /projects?id=eq.1&select=id,name,the_tasks:tasks(id,name),clientes:clients(*)&tasks.order=name.asc&clients.id=eq.1 HTTP/1
.1" 200 146 "" "curl/7.81.0"

Note that:

• The request is repeated on the WARNING message. This is because the error logs go to stderr and access/apache logs to stdout, we can't ensure they appear at the same time.
• Includes all the alias that need to be corrected "tasks to the_tasks, clients to clientes"

TODO

• Add a config that allows user to opt in to this breaking change and removes the warning. Let's have a single config for all cases that can come up in the future. Like server-legacy-features=target-names.
• Tests. fix: unexpected results when embedding the same table twice #4104 didn't include a test that confirms old target names didn't work.
• Loadtests. Add a test in test/load/targets.http that uses the alias to see the impact of this new logic. This should be done in another PR.
• The warning only happens for log-level=warn, this requires Switch to log-level=warn as default #4904 to be effective

[steve-chavez]

Main idea is to add an attribute to ReadPlan, that is then aggregated in App.hs with legacyWarnings to generate the logs. That keeps the Plan module pure.

[laurenceisla]

Includes all the alias that need to be corrected "tasks to the_tasks, clients to clientes"

While working on building this warning, I noticed that we might avoid the breaking change if we look for the filter twice in the list of embeddings:

1. We check if the relation alias is present in the embeddings list and use the filter on that embedding if found
2. If not, then we make the search in the list again, but we look for relation names now

All tests pass when I try this, including the one that revealed the breaking change, but there could be outliers that may still show a breaking change so I'd have to look for them. I think it's worth the try, but before doing that @steve-chavez do you see it as a viable alternative against this whole breaking change warning stuff? (this would still be useful for future breaking changes though)

[steve-chavez]

@laurenceisla I'd say go ahead if you think it's doable without a breaking change (not sure if possible). But we do need to add loadtests for these alias cases to see if the double searching you propose won't cause a noticeable regression.

[wolfgangwalther]

I think we should do the breaking change at some point anyway. The previous behavior was just wrong - once you rename it via an alias, that's the name it should go by. If you want another release with a warning etc. I'd be OK with that. But I'd also be OK without that added complexity and the status quo (the breaking fix as it is currently done on main).

[laurenceisla]

(not sure if possible)
The previous behavior was just wrong

Right, after pondering it for some time, I believe the breaking change is inevitable. Will continue with the TODO list for this PR.

[steve-chavez]

Now that #4904 is closed. Can we still emit the WARNING: logs I mentioend above? I'd think so given it's critical for the administrator to somehow communicate this to clients.

@wolfgangwalther WDYT?