Re: Proposal: Add a UNIQUE NOT ENFORCED constraint

Поиск
Список
Период
Сортировка
От Jacob Jackson
Тема Re: Proposal: Add a UNIQUE NOT ENFORCED constraint
Дата
Msg-id CAAiQw3xBd+sMP2KQdMQGyJwm7LCxuZjnF2rcQRXyBYk+7u655g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Add a UNIQUE NOT ENFORCED constraint  (Robert Treat <rob@xzilla.net>)
Список pgsql-hackers
On Wed, Jan 7, 2026 at 11:13 PM Robert Treat <rob@xzilla.net> wrote:
> Just thinking out loud here, but I wonder if you might be able to
> modify pg_hint_plan to have a "NoUnique" (or "NoOpUnique") hint which
> causes the planner to either skip any unique nodes, or have them
> function as just a passthrough.

This might have its own use cases, but I wouldn't consider that a true
replacement for a unique constraint. It still doesn't solve the table
metadata documentation problem, and it would require modifying all
relevant queries. It also feels like the mental model of everything
then becomes a little convoluted (instead of associating unique
constraints with the data itself, we are now associating it with
queries).

> I'm not entirely sure that's doable
> actually; we don't currently have hints for other types of aggregation
> nodes, and at the moment I don't think we have any hints that can
> produce wrong answers, and this one feels like it could...

It does seem like the ability of these nodes to change results would
introduce difficulties. As I understand, pg_hint_plan's negative hints
primarily operate by removing plans with the node and, therefore,
forcing Postgres to choose a plan without the node. In this case, I
don't think Postgres would present plans without the node in the first
place (or, at least, if the planner did, the plans wouldn't be
otherwise equivalent) because the query planner, not understanding the
unique constraint, treats the plan without the unique node as a
fundamentally different query that will return different results.



В списке pgsql-hackers по дате отправления: