subdir = contrib/cube

top_builddir = ../..

include$(top_builddir)/src/Makefile.global

libdir :=$(libdir)/contrib

NAME= cube

SO_MAJOR_VERSION= 1

SO_MINOR_VERSION= 0

overrideCPPFLAGS += -I$(srcdir)

OBJS= cube.o cubeparse.o cubescan.o buffer.o

all: all-lib$(NAME).sql

include$(top_srcdir)/src/Makefile.shlib

cubeparse.ccubeparse.h: cubeparse.y

$(YACC) -d$(YFLAGS) -p cube_yy$<

mv -f y.tab.c cubeparse.c

mv -f y.tab.h cubeparse.h

cubescan.c: cubescan.l

$(FLEX) $(FLEXFLAGS) -Pcube_yy -o'$@' $<

else

@$(missing) flex $< $@

$(NAME).sql:$(NAME).sql.in

sed -e's:MODULE_PATHNAME:$(libdir)/$(shlib):g'<$<>$@

.PHONY: submake

submake:

$(MAKE) -C$(top_builddir)/src/test/regress pg_regress

installcheck: submake

$(top_builddir)/src/test/regress/pg_regress cube

check:

@echo"'make check' is not supported."

@echo"Do 'make install', then 'make installcheck' instead."

install: all installdirs install-lib

$(INSTALL_DATA)$(srcdir)/README.$(NAME)$(docdir)/contrib

$(INSTALL_DATA)$(NAME).sql$(datadir)/contrib

installdirs:

$(mkinstalldirs)$(docdir)/contrib$(datadir)/contrib$(libdir)

uninstall: uninstall-lib

rm -f$(docdir)/contrib/README.$(NAME)$(datadir)/contrib/$(NAME).sql

cleandistcleanmaintainer-clean: clean-lib

rm -f cubeparse.c cubeparse.h cubescan.c

rm -f y.tab.c y.tab.h$(OBJS)$(NAME).sql

rm -rf results tmp_check log

rm -f regression.diffs regression.out regress.out run_check.out

ifeq ($(PORTNAME), win)

rm -f regress.def

dependdep:

$(CC) -MM$(CFLAGS)*.c>depend

ifeq (depend,$(wildcard depend))

include depend

This directory contains the code for the user-defined type,

CUBE, representing multidimensional cubes.

FILES

-----

Makefilebuilding instructions for the shared library

README.cubethe file you are now reading

buffer.cglobals and buffer access utilities shared between

the parser (cubeparse.y) and the scanner (cubescan.l)

buffer.hfunction prototypes for buffer.c

cube.cthe implementation of this data type in c

cube.sql.inSQL code needed to register this type with postgres

(transformed to cube.sql by make)

cubedata.hthe data structure used to store the cubes

cubeparse.ythe grammar file for the parser (used by cube_in() in cube.c)

cubescan.lscanner rules (used by cube_yyparse() in cubeparse.y)

INSTALLATION

============

To install the type, run

make

make install

For this to work, make sure that:

. the cube source directory is in the postgres contrib directory

. the user running "make install" has postgres administrative authority

. this user's environment defines the PGLIB and PGDATA variables and has

postgres binaries in the PATH.

This only installs the type implementation and documentation. To make the

type available in any particular database, do

psql -d databasename < cube.sql

If you install the type in the template1 database, all subsequently created

databases will inherit it.

To test the new type, after "make install" do

make installcheck

If it fails, examine the file regression.diffs to find out the reason (the

test code is a direct adaptation of the regression tests from the main

source tree).

SYNTAX

======

The following are valid external representations for the CUBE type:

'x'A floating point value representing

a one-dimensional point or one-dimensional

zero length cubement

'(x)'Same as above

'x1,x2,x3,...,xn'A point in n-dimensional space,

represented internally as a zero volume box

'(x1,x2,x3,...,xn)'Same as above

'(x),(y)'1-D cubement starting at x and ending at y

or vice versa; the order does not matter

'(x1,...,xn),(y1,...,yn)'n-dimensional box represented by

a pair of its opposite corners, no matter which.

Functions take care of swapping to achieve

"lower left -- upper right" representation

before computing any values

Grammar

-------

rule 1 box -> O_BRACKET paren_list COMMA paren_list C_BRACKET

rule 2 box -> paren_list COMMA paren_list

rule 3 box -> paren_list

rule 4 box -> list

rule 5 paren_list -> O_PAREN list C_PAREN

rule 6 list -> FLOAT

rule 7 list -> list COMMA FLOAT

Tokens

------

n[0-9]+

integer[+-]?{n}

real[+-]?({n}\.{n}?)|(\.{n})

FLOAT({integer}|{real})([eE]{integer})?

O_BRACKET\[

C_BRACKET\]

O_PAREN\(

C_PAREN\)

COMMA\,

Examples of valid CUBE representations:

--------------------------------------

'x'A floating point value representing

a one-dimensional point (or, zero-length

one-dimensional interval)

'(x)'Same as above

'x1,x2,x3,...,xn'A point in n-dimensional space,

represented internally as a zero volume cube

'(x1,x2,x3,...,xn)'Same as above

'(x),(y)'A 1-D interval starting at x and ending at y

or vice versa; the order does not matter

'[(x),(y)]'Same as above

'(x1,...,xn),(y1,...,yn)'An n-dimensional box represented by

a pair of its diagonally opposite corners,

regardless of order. Swapping is provided

by all comarison routines to ensure the

"lower left -- upper right" representation

before actaul comparison takes place.

'[(x1,...,xn),(y1,...,yn)]'Same as above

White space is ignored, so '[(x),(y)]' can be: '[ ( x ), ( y ) ]'

DEFAULTS

========

I believe this union:

select cube_union('(0,5,2),(2,3,1)','0');

cube_union

-------------------

(0, 0, 0),(2, 5, 2)

(1 row)

does not contradict to the common sense, neither does the intersection

select cube_inter('(0,-1),(1,1)','(-2),(2)');

cube_inter

-------------

(0, 0),(1, 0)

(1 row)

In all binary operations on differently sized boxes, I assume the smaller

one to be a cartesian projection, i. e., having zeroes in place of coordinates

omitted in the string representation. The above examples are equivalent to:

cube_union('(0,5,2),(2,3,1)','(0,0,0),(0,0,0)');

cube_inter('(0,-1),(1,1)','(-2,0),(2,0)');

The following containment predicate uses the point syntax,

while in fact the second argument is internally represented by a box.

This syntax makes it unnecessary to define the special Point type

and functions for (box,point) predicates.

select cube_contains('(0,0),(1,1)', '0.5,0.5');

cube_contains

--------------

t

(1 row)

PRECISION

=========

Values are stored internally as 32-bit floating point numbers. This means that

numbers with more than 7 significant digits will be truncated.

USAGE

=====

The access method for CUBE is a GiST (gist_cube_ops), which is a

generalization of R-tree. GiSTs allow the postgres implementation of

R-tree, originally encoded to support 2-D geometric types such as

boxes and polygons, to be used with any data type whose data domain

can be partitioned using the concepts of containment, intersection and

equality. In other words, everything that can intersect or contain

its own kind can be indexed with a GiST. That includes, among other

things, all geometric data types, regardless of their dimensionality

(see also contrib/seg).

The operators supported by the GiST access method include:

[a, b] << [c, d]Is left of

The left operand, [a, b], occurs entirely to the left of the

right operand, [c, d], on the axis (-inf, inf). It means,

[a, b] << [c, d] is true if b < c and false otherwise

[a, b] >> [c, d]Is right of

[a, b] is occurs entirely to the right of [c, d].

[a, b] >> [c, d] is true if b > c and false otherwise

[a, b] &< [c, d]Over left

The cubement [a, b] overlaps the cubement [c, d] in such a way

that a <= c <= b and b <= d

[a, b] &> [c, d]Over right

The cubement [a, b] overlaps the cubement [c, d] in such a way

that a > c and b <= c <= d

[a, b] = [c, d]Same as

The cubements [a, b] and [c, d] are identical, that is, a == b

and c == d

[a, b] @ [c, d]Contains

The cubement [a, b] contains the cubement [c, d], that is,

a <= c and b >= d

[a, b] @ [c, d]Contained in

The cubement [a, b] is contained in [c, d], that is,

a >= c and b <= d

Although the mnemonics of the following operators is questionable, I

preserved them to maintain visual consistency with other geometric

data types defined in Postgres.

Other operators:

[a, b] < [c, d]Less than

[a, b] > [c, d]Greater than

These operators do not make a lot of sense for any practical

purpose but sorting. These operators first compare (a) to (c),

and if these are equal, compare (b) to (d). That accounts for

reasonably good sorting in most cases, which is useful if

you want to use ORDER BY with this type

There are a few other potentially useful functions defined in cube.c

that vanished from the schema because I stopped using them. Some of

these were meant to support type casting. Let me know if I was wrong:

I will then add them back to the schema. I would also appreciate

other ideas that would enhance the type and make it more useful.

For examples of usage, see sql/cube.sql

CREDITS

=======

This code is essentially based on the example written for

Illustra, http://garcia.me.berkeley.edu/~adong/rtree

My thanks are primarily to Prof. Joe Hellerstein

(http://db.cs.berkeley.edu/~jmh/) for elucidating the gist of the GiST

(http://gist.cs.berkeley.edu/), and to his former student, Andy Dong

(http://best.me.berkeley.edu/~adong/), for his exemplar.

I am also grateful to all postgres developers, present and past, for enabling

myself to create my own world and live undisturbed in it. And I would like to

acknowledge my gratitude to Argonne Lab and to the U.S. Department of Energy

for the years of faithful support of my database research.

------------------------------------------------------------------------

Gene Selkov, Jr.

Computational Scientist

Mathematics and Computer Science Division

Argonne National Laboratory

9700 S Cass Ave.

Building 221

Argonne, IL 60439-4844

selkovjr@mcs.anl.gov