On 08/03/2010 10:39 PM, Lou Picciano wrote:
> Name | Owner | Encoding | Collation |
> Ctype | Access privileges
> -----------------+--------------------+----------+-------------+-------------+-
> <maildb> | <mailowner> | UTF8 | en_US.UTF-8 |
> en_US.UTF-8 | (etc)
That's clean.
>
> I have used sql/postgresql/create_tables.pgsql to build this database.
> Specifically, here's the definition of the dbmail_messageblks table,
> with the bytea messageblk:
>
> CREATE TABLE dbmail_messageblks (
> messageblk_idnr INT8 DEFAULT nextval('dbmail_messageblk_idnr_seq'),
> physmessage_id INT8 REFERENCES dbmail_physmessage(id)
> ON DELETE CASCADE ON UPDATE CASCADE,
> messageblk BYTEA NOT NULL,
> blocksize INT8 DEFAULT '0' NOT NULL,
> is_header INT2 DEFAULT '0' NOT NULL,
> PRIMARY KEY (messageblk_idnr)
> );
As it should be.
>
> Now, wait a minute... This bit of code - from
> sql/postgresql/migrate_from_2.0_to_2.2.pgsql - looks like it may do
> exactly what I need. Can you verify?:
No way! In dbmail 2.0 messageblks was type TEXT, but that created all
kinds of encoding problems. Message blocks had to be stored as-is
without any regard for encoding issues. Hence the bytea storage type.
> if so, again, this is misleading. We built 2.2.16 from scratch, no
> upgrading. So it would make sense that the create scripts would be
> appropriate to the version built by the source tree, no? Perhaps a bit
> of renaming would make sense - simply calling the create_tables.pgsql
> something which indicates its version would be VERY helpful... ! Even
> a little annotation in the header of each file would save a lot of time.
Mmm, I think the current practice of naming the current verions
create_tables makes perfect sense. Only if you upgrade do you need any
of the migration scripts.
>
> The first question: which version of the database does the
> create-tables.pgsql create?
Like I said: the current one for whatever version you are installing.
> Again, is there any simply documentation
> which would help a first-timer know which scripts to step through?
> Seems like there are quite a few gotchas here.
I'm under the impression that most people get along just fine by
following the INSTALL document. But then, I don't do installations from
scratch myself everyday on all backends: only when I'm testing the
create_tables scripts!
I'm under the impression you got off on the wrong foot with your
installation. Something small but critical went wrong. But I don't have
access to solaris, so I can't vouch for that platform. Maybe there's
something in your postgres setup, maybe it's dbmail, I don't know. And I
don't see any way of helping you without detailed forensics or direct
access.
To wit: error_log=5 logs as attachment for the exact test
insertion/retrieval sequence I demonstrated earlier would be a part of
those forensics.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
