[BUGS] BUG #6052: ADD COLUMN - ERROR: tables can have at most 1600 columns
The following bug has been logged online: Bug reference: 6052 Logged by: dinesh Email address: din...@milkorwater.com PostgreSQL version: 8.4.7 Operating system: WIndows 7 pro 64 bit Description:ADD COLUMN - ERROR: tables can have at most 1600 columns Details: I have a table which is used during data uploads, a so-called staging table. This table has a fixed number of columns that [must] match the input CSV file. This CSV file is uploaded using COPY command. Following the COPY, a new column (meant for indexing) is constructed on this table using some application logic; and dropped after that data upload cycle is over. After some 1500+ cycles, I get the following error: ERROR: tables can have at most 1600 columns SQL state: 54011 Context: SQL statement "ALTER TABLE stage_fo ADD COLUMN exch_ticker char varying" So it appears that the command ALTER TABLE stage_fo DROP COLUMN exch_ticker is only producing some soft effects, not sufficient for the db engine. There was a similar problem mentioned by another user, Ron St-Pierre, in June 2004 (http://bytes.com/topic/postgresql/answers/422107-error-tables-can-have-most -1600-columns). Suggestion made there - to drop/rebuild the table - is not a trivial choice. I will appreciate any helpful pointers that will get us past this showstopper. Rewrite is going to be expensive. Thanks & regards Dinesh Dinesh -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6049: Can't load dumped view with VALUES and ORDER BY
"Dylan Adams" writes: > If you create a view based on a VALUES statement with an ORDER BY clause, > the SQL produced by pg_dump can't be loaded back into the database. I've applied a patch for this. Thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6051: wCTE query fail with wrong error text on a table with rules
Merlin Moncure writes: > On Fri, Jun 3, 2011 at 10:42 AM, Jehan-Guillaume (ioguix) de Rorthais > wrote: >> test=# CREATE RULE test_ins AS ON INSERT TO test DO INSTEAD INSERT INTO >> test2 VALUES (NEW.i); >> CREATE RULE >> test=# WITH t1 AS ( >> DELETE FROM ONLY test RETURNING * >> ) >> INSERT INTO test SELECT * FROM t1; >> ERROR: could not find CTE "t1" > IIRC the fact that rules don't play nice with wCTE was brought up > several times during the implementation discussions. I'm not saying > the error message is great, but you can pretty much add this to the > giant pile of reasons not to use rules at all (particularly in 9.1 > with the view triggers). There are definitely cases that don't work, but I had thought we at least threw an intelligible "not implemented" error for all of them. This one seems to be an oversight: specifically, rewriteRuleAction() isn't considering the possibility that the rewritten rule action will need to make use of CTEs from the original query. We could paste a copy of the original's cteList into the rule action, but there are still issues: * If there's more than one rule action, we could end up executing multiple copies of the same CTE query; which breaks the expectation of single evaluation for a CTE. * If there are CTEs attached to the rule action, as well as to the original query, and there is a conflict of CTE names between them, we can't handle that AFAICS. (The planner expects to look up entries in a cteList by name...) * Maybe some other things that aren't obvious yet. I don't particularly mind throwing a not-implemented error for the first case (ie, just say multiple rule actions don't mix with CTE queries); but the second case seems seriously annoying, since there's no way for someone to write a CTE-containing rule action without risking a conflict. Ideas anybody? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
