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/