From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Duplicate unique key values in inheritance tables |
Date: | 2024-07-16 01:01:15 |
Message-ID: | CAApHDvo9LJN8PpOzfh5FBy_PVX5e=NzBKceOYRy-Zh7=8KZY3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 16 Jul 2024 at 12:45, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> As a workaround for this issue, I'm considering whether we can skip
> checking functional dependency on primary keys for inheritance
> parents, given that we cannot guarantee uniqueness on the keys in this
> case. Maybe something like below.
>
> @@ -1421,7 +1427,9 @@ check_ungrouped_columns_walker(Node *node,
> Assert(var->varno > 0 &&
> (int) var->varno <= list_length(context->pstate->p_rtable));
> rte = rt_fetch(var->varno, context->pstate->p_rtable);
> - if (rte->rtekind == RTE_RELATION)
> + if (rte->rtekind == RTE_RELATION &&
> + !(rte->relkind == RELKIND_RELATION &&
> + rte->inh && has_subclass(rte->relid)))
> {
> if (check_functional_grouping(rte->relid,
>
> Any thoughts?
The problem with doing that is that it might mean queries that used to
work no longer work. CREATE VIEW could also fail where it used to
work which could render pg_dumps unrestorable.
Because it's a parser issue, I don't think we can fix it the same way
as a5be4062f was fixed.
I don't have any ideas on what we can do about this right now, but
thought it was worth sharing the above.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Imran Khan | 2024-07-16 01:14:25 | Re: filesystem full during vacuum - space recovery issues |
Previous Message | Laurenz Albe | 2024-07-16 00:58:43 | Re: filesystem full during vacuum - space recovery issues |