I've had the same problems using rc 4.
so far since i'm on the testing stage to decide if we're using this great tool or not I've been doing some tweaking to the types in the database and a few more WHERE statements.
I'm using debian as well, and since i'm not that familiar with epesi i reverted to checking the debugs of the postgresql-8.3 logs, i found that most of the code treated tgenabled as a boolean, which is a char and well, the old story of the implicit cast removal falls into place.
For this i had to change:
before:
FROM pg_trigger t WHERE t.tgenabled AND
after:
FROM pg_trigger t WHERE t.tgenabled <> \'D\' AND
to find the files i first entered to the epesi directory and then issued a
for I in `grep -R tgenabled *|gawk -F: '{ print $1 }'|sort -u`; do vim $I; done
i edited the entries and then i got another database error from f_longterm
ALTER TABLE task_data_1 ALTER COLUMN f_longterm TYPE TEXT;
I doubt "text" is a good idea but i'll work on performance/tuning later on.
and another one from f_login
ALTER TABLE contact_data_1 ALTER COLUMN f_login TYPE text;
Then it all worked good while adding things here and there, until i tried editing a project's ticket when i got a complain about premium_ticket_datas_1's field id which defaults to a sequence's nextval (premium_tickets_data_1_id_seq)...
I did a quick test with:
ALTER TABLE premium_tickets_data_1 ALTER COLUMN id TYPE varchar(8);
And ticket edition/addition/deletion worked fine.
So far everything is working great and i'm trying to test all the modules' functions to create a stable environment and launch this into production, Let's hope i'm not breaking too much code with this.
