Re: Duplicate unique key values in inheritance tables

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Duplicate unique key values in inheritance tables
Date: 2024-07-18 10:25:50
Message-ID: CAApHDvqG=4=yRodYDFXYcujn8z+tiyUWsgUwUEN-cCZZEA9XZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 16 Jul 2024 at 13:28, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> Add another note to caveats in the docs and call it a feature. We produce a valid answer for the data model encountered. The non-determinism isn’t wrong, it’s just a poorly written query/model with non-deterministic results. Since v15 we have an any_value aggregate - we basically are applying this to the dependent columns implicitly. A bit of revisionist history but I’d rather do that than break said queries. Especially at parse time; I’d be a bit more open to execution-time enforcement if functional dependency on the id turns out to have actually been violated. But people want, and in other products have, any_value implicit aggregation in this situation so it’s hard to say it is wrong even if we otherwise take the position that we will not accept it.

I think it might be best just to ignore it and do nothing. Maybe it
would be worth putting something into the docs about it if people from
userland come complaining about a bug as the doc mention might stop
them wasting their time reporting something we already know about.
Otherwise, I feel the docs would just draw attention to something that
I'd personally rather people didn't do. As you say, using any_value()
would be the way we'd encourage people to do it if they don't care
which value of the ungrouped column they want, so documenting
something else doesn't seem quite right to me.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2024-07-18 10:25:55 Re: Set log_lock_waits=on by default
Previous Message Nitin Motiani 2024-07-18 10:17:26 Re: long-standing data loss bug in initial sync of logical replication