I've updated db schema, thanks for the tip. It seams like dbmail doesn't insert empty string. There is no such string in dbmail_headervalue table after passing sort-subject test (all other values are there). So COALESCE workaround may be of some help here.
I guess I figured out why sorting fails for "_". It's a locale-specific issue, and when I exported LC_ALL=C sort output was like this: a a a a_a _ Unfortunately it's not possible to change existing PostgreSQL db's locale, it can be set only while creating db (initdb --locale=C). But whether C-locale is required or not is not clear. RFC says: "the SORT and THREAD extensions MUST collate strings according to the i;unicode-casemap collation described in [ UNICASEMAP ]." Понедельник, 5 августа 2013, 13:11 +02:00 от Paul J Stevens <p...@nfg.nl>: >On 08/05/2013 12:11 PM, . . wrote: >> In the latest version sorting order is changed to "sortfield", but table >> (view) is left the same: "subjectfield". >> Probably it should be changed to "sortfield" too. > >No the view was not left unchanged. > >If you did a full configure/make/make install, dbmail will automatically >run any necessary schema migrations. > >You can tell be looking at the tables. You should have a >dbmail_upgrade_steps table, and the dbmail_subjectfield view now also >contains a sortfield field. > >> Also according RFC 5256: "If the associated RFC-822 >> < http://tools.ietf.org/html/rfc822 > header for a particular criterion is >> absent, it is treated as the empty string. The empty string always >> collates before non-empty strings." > >Correct. That is why the sort-subject tests still fail. > >> But with PostgreSQL as backend db dbmail puts NULL strings always at the >> end of the resulting set. >> To fix this we may apply COALESCE function on sortfield: >> _append_sort(value->order, "COALESCE(sortfield, '')", reverse); > >That is one way to do it, but DBMail should always insert an empty >string for messages that don't have a subject header. > >> It helps to pass imaptest's sort-subject test a bit further. >> >> The only issue left is that PostgreSQL puts header string "_" before all >> other non empty strings, whereas imaptest puts it at the end after all >> headers in test. >> I haven't found out how to fix this yet (maybe it's imaptest's issue). > >It looks like imaptest is at fault here. Doing a simple test with >sort(1) confirms postgresql's behavior. > >$~> cat > /tmp/test.txt << EOF >a_a > a >_ >a a >EOF >$~> cat /tmp/test.txt|sort -f > >_ > a >a a >a_a >$~> > >But maybe such characters have to be treated differently for some reason. >-- >________________________________________________________________ >Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin > > * Premium Hosting Services and Web Application Consultancy * > > www.nfg.nl/i...@nfg.nl/+31.85.877.99.97 >________________________________________________________________ -- . .
_______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
