Stop recommending psycopg3 connection strings on older Airflow

[shahar1]

Human Summary

This PR fixes psycopg connection-string guidance for older Airflow versions than 3.2.
It replaces psycopg3 connection strings with psycopg2 for compatibility with those versions.

AI Summary

Click here

The amazon executor setup guides and the Celery `result_backend` example tell users to configure a `postgresql+psycopg://` (psycopg3) connection string. Both providers declare `apache-airflow>=2.11.0`, and releases before Airflow 3.2.0 (the first with a `sqlalchemy>=2.0` floor) can run on SQLAlchemy 1.4, which has no `postgresql+psycopg` dialect at all — a user following those instructions gets `sqlalchemy.exc.NoSuchModuleError` at startup, with nothing in the docs indicating the advice was version-specific.

The amazon guides are step-by-step deployment instructions where the connection string is pasted straight into an AWS console field, so the wrong value is especially easy to pick up.

This switches the documented value to postgresql+psycopg2://, which is valid on every Airflow version these providers support, and moves the version guidance into prose so the code block stays copy-pasteable. The three amazon executor guides had the same block duplicated inline; they now include a single shared block from general.rst, matching how the rest of those files already share content. The celery result_backend note also scopes the psycopg3 default to what actually governs it: the derivation applies to a driverless postgresql:// URL when SQLAlchemy 2.0 and psycopg are both installed.

Verified with breeze build-docs amazon celery (build and spellcheck) — both packages pass and all affected pages render correctly.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[uranusjr]

If this is for older Airflow, should this be filed to versioned branches instead of main?

[potiuk]

If this is for older Airflow, should this be filed to versioned branches instead of main?

It's not - providers currently (cc: @eladkal) support Airlfow 2.11+ from main - until we make a decision they don't

[eladkal]

If specific providers will benfit from bumping min airflow version lets talk.

[potiuk]

If specific providers will benfit from bumping min airflow version lets talk.

I think that's about 100 conversation fior you to have, But yeah, I am interesting to see how many extra conversations and failures to handle it will bring. 👀

[Dev-iL]

Small suggestion, otherwise lgtm

[shahar1]

If specific providers will benfit from bumping min airflow version lets talk.

I don't think that specific providers will benefit from that - we'll have to bump to 3.2+ and handle dropping 2.11-3.1 just for a doc example.