24577 Commits

Author	SHA1	Message	Date
asfernandes	c7a4808105	increment build number	2008-12-21 15:33:06 +00:00
robocop	e2b1b3e549	increment build number	2008-12-21 10:57:24 +00:00
robocop	5ccf313d65	Collapse two cases being exactly the same.	2008-12-21 10:57:23 +00:00
robocop	79f67bab43	increment build number	2008-12-21 10:49:50 +00:00
dimitr	1100c71c26	increment build number	2008-12-21 06:35:57 +00:00
dimitr	05299f653e	Fixed CORE-1607: Correlated subquery is optimized badly if it depends on the union stream.	2008-12-21 06:29:47 +00:00
dimitr	0c68ac9563	increment build number	2008-12-21 06:29:46 +00:00
robocop	941f7594e5	increment build number	2008-12-21 06:13:13 +00:00
robocop	527f73c7c4	increment build number	2008-12-21 06:12:43 +00:00
robocop	32cb8c32f8	increment build number	2008-12-21 06:12:42 +00:00
robocop	78df1ae72d	Style.	2008-12-21 06:12:41 +00:00
robocop	f8af66385d	increment build number	2008-12-21 03:50:30 +00:00
robocop	e63b46bb9c	There's no need to check whether a pointer is null before applying delete or delete[].	2008-12-21 03:50:29 +00:00
robocop	cf6905e56d	increment build number	2008-12-21 03:39:33 +00:00
robocop	88acb3d7ec	increment build number	2008-12-21 03:37:58 +00:00
robocop	20766e4982	increment build number	2008-12-21 03:31:46 +00:00
robocop	721335df6f	Restore Adriano's code.	2008-12-21 03:31:44 +00:00
asfernandes	26bac0f322	increment build number	2008-12-20 23:50:24 +00:00
asfernandes	432d7c5bfa	increment build number	2008-12-20 23:50:23 +00:00
asfernandes	42712a391f	increment build number	2008-12-20 23:50:21 +00:00
asfernandes	a946b4cd5c	increment build number	2008-12-20 23:50:20 +00:00
asfernandes	ee60919781	increment build number	2008-12-20 23:50:19 +00:00
asfernandes	6c2faca756	increment build number	2008-12-20 23:50:18 +00:00
asfernandes	b9065d5af5	increment build number	2008-12-20 23:50:16 +00:00
asfernandes	54ff616710	increment build number	2008-12-20 23:50:15 +00:00
asfernandes	55c5b6afa4	increment build number	2008-12-20 23:50:14 +00:00
asfernandes	e2d8cda4dc	increment build number	2008-12-20 19:57:45 +00:00
asfernandes	bb587d8ee7	increment build number	2008-12-20 19:57:44 +00:00
asfernandes	5311dd5a5e	Misc	2008-12-20 19:57:43 +00:00
asfernandes	ad9acb0eef	increment build number	2008-12-20 19:57:42 +00:00
fsg	8c1cc3433c	increment build number	2008-12-20 19:38:42 +00:00
asfernandes	bfc867546d	increment build number	2008-12-20 15:17:44 +00:00
asfernandes	dd9dd9d704	increment build number	2008-12-20 15:16:06 +00:00
robocop	287883e5f1	increment build number	2008-12-20 08:18:33 +00:00
robocop	b379912e34	increment build number	2008-12-20 08:16:57 +00:00
robocop	ccf408584e	increment build number	2008-12-20 08:16:56 +00:00
robocop	9c9e4e9b0b	There's no need to check whether a pointer is null before applying delete or delete[].	2008-12-20 08:16:55 +00:00
robocop	0a961cdc6a	increment build number	2008-12-20 08:16:54 +00:00
robocop	f876a42fa3	increment build number	2008-12-20 08:12:21 +00:00
robocop	6ac3079962	increment build number	2008-12-20 08:12:20 +00:00
robocop	95292d1731	Style.	2008-12-20 08:12:19 +00:00
robocop	1da93183da	increment build number	2008-12-20 08:12:18 +00:00
robocop	9771b2554c	increment build number	2008-12-20 08:12:17 +00:00
fsg	f96a2b19e9	increment build number	2008-12-19 19:38:31 +00:00
alexpeshkoff	7fe34d245a	increment build number	2008-12-19 15:41:22 +00:00
dimitr	fd53ec0746	increment build number	2008-12-19 14:59:43 +00:00
dimitr	549db36cb9	increment build number	2008-12-19 14:58:17 +00:00
dimitr	78037bfe40	Fix for big-endian machines, it follows Alex's set of fixes.	2008-12-19 14:58:16 +00:00
dimitr	65da895f73	increment build number	2008-12-19 14:57:02 +00:00
dimitr	2b87e94242	Use explicit iterators instead of the implicit (built-in) ones due to the thread-safety requirements. ... This change affects GenericMap only, as it's used globally in a few places and we have a proven crash there. I have a more complete solution (total cleanup of default accessors from BePlusTree and SparseBitmap) in my local tree (thanks to Dmitry Kovalenko), but it's incomplete (requires more changes inside the engine) and IMHO risky (~20 core modules are affected), so I'd like to defer finalization of this cleanup till v3.0. All objects of these types seem being protected by dbb_sync, so they shouldn't cause us any problems currently.	2008-12-19 14:57:01 +00:00