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 по дате отправления: