On Thu, 2005-12-15 at 09:46 +0100, Paul J Stevens wrote: > Kevin Brown wrote: > > Aaron Stone wrote: > > > >>Something without a subquery is needed, as the 2.0 series must continue > >>to work with MySQL 4.0.x. > > > > > > We can't just force people to upgrade to 4.1.x? It'd be good for > > them. Forcing them to upgrade to PostgreSQL would be even better. > > Hey, I can dream, can't I? :-) > > 4.1.x or better will be required for 2.2 but for 2.0 we have to stick with > 4.0, > alas. And I suspect 5.0 will be become a requirement for 2.3+ so we can start > working with views, triggers, etc...
I know we talked about this earlier, but I think for 2.2 we need to make it possible to have multiple queries- we talked about it per database layer, but why not a global conformance level setting? DB_CAN_VIEW DB_CAN_TRIGGER DB_CAN_SUBSELECT DB_CAN_FOREIGNKEY (etc) and select the appropriate query at that point? I mean, dbmail knows what queries it uses, and I don't suggest for a moment that dbmail should attempt to find optimal queries for suboptimal (read: old) databases, but if dbmail 2.0 works with 4.0 then 2.2 should as well, otherwise we'll be making upgrades hell for users. > > Anyway, there's no way to portably generate an inline "table" any > > other way that I know of, which means a truly "portable" solution that > > includes MySQL 4.0.x is going to involve doing something like the > > array index trick I mentioned originally. > > > > I certainly don't mind implementing that, though Paul seemed a little > > underwhelmed with that solution... > > It's just that I'm more concerned with maintainability, clarity of coding > style, > clean orthogonal apis. I've spent the last year and a half working to cleanup > loads of smart performance hacks stacked upon each other until no-one dared > touch those parts of the code (i.e. the plate spagetti comprised by _ic_fetch, > the msgbuf global cache and the internal mime parser). I'm just a bit wary of > implementing optimizations in code that needs overall redesign anyway. I completely agree with this. There's just the problem of databases being a moving target. Remember we talked about COUNT(*) not being optimally implemented in Pg, but one day it could be, and at that point, we should use COUNT(*) - even if it's slower on older database versions. But for right now, those absolutely disgusting performance hacks are absolutely necessary. SQL, as awesome as it is, has to make generic decisions, and each database provider makes those decisions differently- based on what their code presently looks like, what their users do, and so on. SQLite optimized count(*) a long time ago- probably because it was easy for them, and Pg has been talking about it forever and hasn't done it because for them it's hard-- not to suggest Pg is written by less competent programmers, but pointing out that there are things that are fast in Pg, things that are fast in SQLite, and I'm sure there are things that are fast in MySQL- they're just all different. A good way to help avoid those hacks is a conformance macro like I described. That way someone poking around at the code can see multiple (equivalent!) operations so that with the simpler- more straightforward SQL- they can probably better determine what the more complex (hacky) operations are trying to do. ... As a side note: I've been working on minimime recently for doing a single pass decoding of MIME message parts. It doesn't require we load the whole message into memory for parsing (!) http://gpl.internetconnection.net/ It's presently in the "mimepipe" package, which simply runs an exe for each mime part decoded on stdin, i.e. mimepipe /bin/sh -c 'gzip -9 > part.$$.gz' < mm.eml Produces a bunch of part.####.gz files containing the decoded portions of mm.eml It uses yacc/lex to build the parser, so overriding the yy/buffer code would all that would be necessary to get data from the SQL engine... Presently, there's still some bugs: esp. in obtaining the preamble from the MIME message, but I don't actually think that's accessible using a BODY[part] syntax... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
