On 2021-Aug-18, Tom Lane wrote:
> I wonder though if we could fix the immediate problem with something
> less ambitious. The hard part of the full proposal, I think, is
> separating permanent identity from physical position. If we were to
> split out *only* the display order from that, the patch footprint
> ought to be far far smaller --- basically, I think, we'd need to fix
> star-expansion and not a lot more in the backend. Of course,
> client-side code like psql's \d and pg_dump would need to be upgraded
> too, but any missed things there would be cosmetic that's-not-the-
> expected-column-order bugs, not core dumps. Also, at least in the v1
> patch we could use this just for system catalogs without exposing it
> as a feature for user tables, which would greatly restrict the set of
> client-side places that really need fixed.
>
> (I think Alvaro was the last person to mess with this issue, so I
> wonder what his take is on the feasibility of such a restricted
> solution.)
Yeah, my impression is that the project of just changing star expansion
is much, much easier than splitting out attribute identity from physical
location. The former, as I recall, is a localized change in expandRTE
and friends, and you don't have to touch anything else. The other part
of the change is much more invasive and got me into territory that I
wasn't able to navigate successfully.
(I think we should consider keeping 'attnum' as the display-order
attribute, and have the physical-and-identity attribute get a new name,
say attphysnum. That's so that you don't have to change psql and the
whole world -- the change is transparent to them. This means we need a
first step that's very invasive, because every single current use of
'attnum' has to be changed to attphysnum first, followed by a functional
patch that changes a few of those back to attnum. It'd be a large
inconvenience to backend developers to ease the lives of client-side
developers.)
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
