Tom Lane wrote:
>Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
>
>
>>On Sun, Jun 27, 2004 at 11:11:32AM -0700, Ron St-Pierre wrote:
>>
>>
>>>STATEMENT: ALTER TABLE victoria.eodData DROP COLUMN tickDate;
>>>ERROR: tables can have at most 1600 columns
>>>STATEMENT: ALTER TABLE victoria.eodData ADD COLUMN tickerID INTEGER;
>>>ERROR: tables can have at most 1600 columns
>>>
>>>
>
>
>
>>Have you done the DROP COLUMN/ADD COLUMN cycle to this table more than,
>>say, 1500 times? Because a dropped column is actually only hidden from
>>the user, but it's still present to the system and it will still affect
>>the 1600 limit.
>>
>>
>
>That is a good theory, but it doesn't quite explain why Ron's getting
>the error from DROP COLUMN --- AFAICS, the places that would issue such
>an error won't get called in that path.
>
>I tried to reproduce this and could not: after 1600 cycles of adding and
>dropping a column, I did indeed start to get "tables can have at most
>1600 columns" from ADD, but DROP continued to behave normally.
>
>Ron, are you sure these errors were coming from the DROPs and not only
>the ADDs? Can you exhibit a test case?
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
>
I re-checked the logs and saw that the error only ocurred on trying to
add the column, sorry for the cut-and-paste mistake. But before that I
tried a test script and had the same result that Tom did. I think that
I'll take Scott's advice and probably use INSERT INTO to re-create the
table each time and avoid the 1600 column error. I am currently using
TRUNCATE to clear the table before each use but it obviously doesn't
re-set the column count.
Thanks again for your help.
Ron
