Thank you all for your answers.
David and Tom's answers are more than enough to feed my argument to the developers. =)
Scott, you're right of course. My first action to reestablish their development database was to do a dump/restore, but by logging DML statements I can see the application is dropping and adding the same column over and over again, so it's a matter of time before it hangs. I hope showing this thread to the developers will make them see some sense.
@Wells, don't ask me, I have no idea, hahah, but it's a small table and the application keeps dropping/readding the column, actually. I figure the developer is using some kind of crazy ORM that drops the column when he deletes an object property and re-adds it when he sets the property back or something.
@Ervin, a vacuum full doesn't "fix" this behavior, since it's expected after all =)
collimittest=# \d add_drop_text
Table "public.add_drop_text"
Column | Type | Collation | Nullable | Default
--------+------+-----------+----------+---------
fixed | text | | |
collimittest=# vacuum FULL ANALYZE VERBOSE add_drop_text ;
INFO: vacuuming "public.add_drop_text"
INFO: "add_drop_text": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL: 0 dead row versions cannot be removed yet.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: analyzing "public.add_drop_text"
INFO: "add_drop_text": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
VACUUM
collimittest=# alter table add_drop_text add column x int;
ERROR: tables can have at most 1600 columns