David Rowley <dgrowleyml@gmail.com> writes:
> On Thu, 29 Jul 2021 at 16:08, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> So, it is not a bug, and, IMO, it is not a limitation worth removing.
> I'm not sure if I agree that it's "explicitly documented". All that
> text mentions is that you can't have more than 1600 columns in a table
> at once. What the OP is complaining about are that attnums are not
> recycled and that if you continually add and drop columns you can run
> out well before you have 1600 columns.
Right, but why is that a usage pattern that is worth the very large
increment in complexity that would be involved in supporting it?
The fundamental reason why we can't just "recycle attnums" is that the
attnums are effectively primary keys, ie permanent unique identifiers,
for columns. A table's attnums propagate into views on the table,
foreign key data in other tables, etc etc. So renumbering attnums
would involve updating those other objects and therefore taking
exclusive locks on them, which creates a lot of issues.
It's possible that some of this could be dodged if we ever finish
the project of decoupling logical and physical column positions.
What was being talked about there was having three identifiers
for a column (permanent ID, logical index, physical index).
If we didn't restrict the range of permanent IDs then the problem
goes away, at least till you overrun an int16 or int32.
But anyway, I'm skeptical that there is a use-case here that
justifies a lot of work to fix. Why is it a good idea to
drop and re-add a column over and over?
regards, tom lane