From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Denis Garsh <d(dot)garsh(at)arenadata(dot)io> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add system column support to the USING clause |
Date: | 2024-09-13 14:56:19 |
Message-ID: | 86136.1726239379@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Denis Garsh <d(dot)garsh(at)arenadata(dot)io> writes:
> The patch adds support for system columns in JOIN USING clause.
I think this is an actively bad idea, and it was likely intentional
that it's not supported today. A few reasons why:
* There are, fundamentally, no use-cases for joining on system
columns. The only one that is stable enough to even consider
using for the purpose is tableoid, and I'm not detecting a reason
why that'd be useful. If there are any edge cases where people
would actually wish to do that, it can be done easily enough with
a standard JOIN ON clause.
* Non-heap table AMs may not provide the same system columns that
heap does, further reducing the scope for plausible use-cases.
(Yeah, I know we don't support that too well today.)
* This breaks ruleutils.c's mechanism for dealing with name
conflicts across multiple USING clauses. That relies on being
able to assign aliases to the USING inputs at the table level
(that is, "FROM realtable AS aliastable(aliascolumn,...)").
There's no way to alias a system column in the FROM syntax.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-09-13 14:56:21 | Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible |
Previous Message | jian he | 2024-09-13 14:42:00 | Re: Emitting JSON to file using COPY TO |