David's answer is right. Basically every column added gets an index # which is not recycled.
I just want to add that a dump/restore will not bring in the history of deleted columns, thus resetting the column
counterfor the table.
--
Scott Ribe
scott_ribe@elevated-dev.com
https://www.linkedin.com/in/scottribe/
> On Jun 6, 2018, at 10:51 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Wed, Jun 6, 2018 at 9:39 AM, nunks <nunks.lol@gmail.com> wrote:
> I reproduced this behavior in PostgreSQL 10.3 with a simple bash loop and a two-column table, one of which is fixed
andthe other is repeatedly dropped and re-created until the 1600 limit is reached.
>
> To me this is pretty cool, since I can use this limit as leverage to push the developers to the right path, but
shouldPostgres be doing that? It's as if it doesn't decrement some counter when a column is dropped.
>
> This is working as expected. When dropping a column, or adding a new column that can contain nulls, PostgreSQL does
not,and does not want to, rewrite the physically stored records/table. Thus it must be capable of accepting records
formedfor prior table versions which means it must keep track of those now-deleted columns.
>
> I'm sure that there is more to it that requires reading, and understanding, the source code to comprehend; but that
doesseem to explain why its works the way it does.
>
> David J.
>