The first part is unnecessary and in incorrect hardcoding. Missing 
sequences are already catched in the migration scripts.

For the second part I'm not sure either. First of all, it should not 
contain and debug code, and the conversion should be unconditionally 
when converting to binary.
Without taking a closer look at the code, the correct fix would 
probably be to do this in the base driver and  loop all values there 
and write them back using Horde_Db_Value.

during our migration from Horde3 to Horde5 with a Postgresql database, I
have two problems with SQL commands:

a)
2013-09-25 13:05:09 CEST STATEMENT:  DROP SEQUENCE
turba_shares_share_id_seq CASCADE
2013-09-25 13:05:09 CEST ERROR:  "turba_shares_seq" is not a table
2013-09-25 13:05:09 CEST HINT:  Use DROP SEQUENCE to remove a sequence.

the script tries to drop a squence with DROP TABLE.
Tested on Postgres v8.4.17-0squeeze1.

b)
2013-09-25 13:11:46 CEST STATEMENT:  ALTER TABLE "horde_prefs" ALTER
COLUMN "pref_value" TYPE bytea
2013-09-25 13:11:46 CEST ERROR:  invalid input syntax for type bytea

Postgres cannot cast TEXT to BYTEA, whyever ... .
see
https://drupal.org/node/1031122#comment-6219708
http://www.postgresql.org/docs/8.3/static/datatype-binary.html
http://www.postgresql.org/docs/8.0/static/functions-binarystring.html

Tested on Postgres v8.4.17-0squeeze1 and 8.1.19-0etch1.

=============================================

Attached patch contains a workaround for a) in dropTable()  by using 
DROP SEQUENCE if the name ends in _seq.

For b) I extended Db/Adapter/Postgresql/Schema.php with a special 
conversation text->binary according link #1 above, which seems to be 
backed by the postgresql.org links. One could add the conversion to a 
ALTER TABLE command, but then I had to make the patch larger. The many 
backslashes are required, because first PHP and then SQL expands the 
backslashes a second time, hence, the E'\\\\' becomes plain '\'.