From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access |
Date: | 2023-03-30 17:33:40 |
Message-ID: | 251604.1680197620@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2023-Mar-29, Tom Lane wrote:
>> We should probably just disallow system columns as foreign keys.
>> There was a legitimate use-case for that with OID columns, but
>> no more.
> +1
Seems pretty easy, as attached. The possibly harder question is whether
to back-patch this, or to try to fix the problems Alexander identified
in the back branches.
Some investigation determined that system columns in foreign keys
appear to actually work up through v11, which perhaps coincidentally
is the last version that allowed the OID system column. v12 and up
have the slot_attnum problem that Alexander showed. The lack of
complaints about that suggests that nobody is trying to use any other
system columns as FKs in production. Nonetheless, it's a bit worrisome
to remove a feature-that-used-to-work in stable branches.
On balance though, I'd rather block this than promise to make it work
in the back branches. I propose applying the attached back to v12,
and leaving v11 alone.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
disallow-system-columns-in-foreign-keys.patch | text/x-diff | 4.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-30 19:50:05 | Re: BUG #17871: JIT during postgresql_fdw remote_estimates EXPLAIN have very negatively effect on planning time |
Previous Message | Tom Lane | 2023-03-30 15:35:03 | Re: BUG #17876: Function width_bucket() for float8 input returns value out of range |