Hello There is new version of patch. I have separated ordering operators to different patch (https://commitfest.postgresql.org/action/patch_view?id=1243), fixed formatting issues and implemented backward compatibility with old-style points in cube_is_point() and cube_out().
Also comparing output files I've discovered that this four files is combination of two types of different behavior: 1) SELECT '-1e-700'::cube AS cube; can be (0) or (-0) 2) Amount of zeros in exponent of floating point, i.e. SELECT '1e27'::cube AS cube; can be (1e+027) or (1e+27) On my system (OSX) it is second option in both situations. I've also tested it on FreeBSD 9.0 and Ubuntu 12.04 with the same results. So is there some ideas how can I reproduce such results? Stas.
points.diff
Description: Binary data
On Sep 16, 2013, at 10:48 AM, Heikki Linnakangas wrote: > On 12.07.2013 14:57, Stas Kelvich wrote: >> Hello. >> >> here is a patch adding to cube extension support for compressed >> representation of point cubes. If cube is a point, i.e. has coincident lower >> left and upper right corners, than only one corner is stored. First bit of >> the cube header indicates whether the cube is point or not. Few moments: >> >> * Patch preserves binary compatibility with old indices >> * All functions that create cubes from user input, check whether it is a >> point or not >> * All internal functions that can return cubes takes care of all cases where >> a cube might become a point > > Great! > > cube_is_point() needs to still handle old-style points. An NDBOX without the > point-flag set, where the ll and ur coordinates for each dimension are the > same, still needs to be considered a point. Even if you are careful to never > construct such structs in the code, they can be present on-disk if you have > upgraded from an earlier version with pg_upgrade. Same in cube_out(). > >> * Added tests for checking correct point behavior > > You'll need to adjust all the expected output files, not only cube_1.out. > >> Also this patch includes adapted Alexander Korotkov's patch with kNN-based >> ordering operator, which he wrote for postgresql-9.0beta1 with knngist >> patch. More info there >> http://www.postgresql.org/message-id/aanlktimhfaq6hcibrnk0tlcqmiyhywhwaq2zd87wb...@mail.gmail.com > > To make review easier, it would be better to keep that as a separate patch, > actually. Could you split it up again, please? > > - Heikki
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
