> > X-OfflineIMAP-901701146-4c6f63616c4d69726a616d-494e424f58:
> > 1086726519-0790956581151
>
> Searches for p.e. X-Spam-Status are quite common too.
>
> Aaron: more returned rows make a real difference if the imapd and
> database are on different hosts.
>
> The point I don't see in this discussion is: where is the problem using
> the is_header column even if that requires running a script or
> program in the 2.0 series? The database structure stays the same, people
> don't need to change any software, they can switch between old and new
> dbmail of 2.0 series so it won't hurt but we gain a lot.
Couldn't this be solved by having a headers table like this?
Create table headers(
hid serial primary key,
physmessage_id int not null,
header varchar not null,
value varchar not null,
);
create index headers_physid_header on headers(physmessage_id,header);
This would let us do the following:
Select value from headers where physmessage_id='4' AND header='From';
Note that there are headers with the same name that there can be
several of in a mail. (ex: several Recieved: headers) This would work
fine with this setup.
The index is multi column so that headers is indexed for
each physmessage_id value. This should give us a very nice speed.
It is not the very fastest solution to get common header fields, but
it is much faster than todays solution, and also usable for uncommon
fields of any kind.
The original header could just stay where it is today, and the is_header
field could be made active or removed.
This would not make it any different for 3'rd party programs that parse
the header field today. Yet much faster for those who choose to use the
(much simpler) headers table.
-=Dead2=-
