From: | Daniel Brinzila <briuz001(at)umn(dot)edu> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Recent 11.16 release change |
Date: | 2022-06-14 19:30:47 |
Message-ID: | CAHVn1Am3dZuNZDwGd_+X9hOL7L5RPejLr8r=3N+DS=2Wg4pT8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I am a bit confused as to the following change:
-
Stop using query-provided column aliases for the columns of whole-row
variables that refer to plain tables (Tom Lane)
The column names in tuples produced by a whole-row variable (such as
tbl.* in contexts other than the top level of a SELECT list) are now
always those of the associated named composite type, if there is one. We'd
previously attempted to make them track any column aliases that had been
applied to the FROM entry the variable refers to. But that's
semantically dubious, because really then the output of the variable is not
at all of the composite type it claims to be. Previous attempts to deal
with that inconsistency had bad results up to and including storing
unreadable data on disk, so just give up on the whole idea.
In cases where it's important to be able to relabel such columns, a
workaround is to introduce an extra level of sub-SELECT, so that the
whole-row variable is referring to the sub-SELECT's output and not to a
plain table. Then the variable is of type record to begin with and
there's no issue.
Could someone please give an example of this scenario, one that works in
11.15 and another for 11.16 after the recent change.
Thanks!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-06-14 21:23:15 | Re: Recent 11.16 release change |
Previous Message | Tom Lane | 2022-06-14 16:09:16 | Re: Postgres NOT IN vs NOT EXISTS optimization |