- developers-list - monetdb.org

[Monetdb-developers] MONET-PHP
by Goker Burak Cetin 19 Dec '05

19 Dec '05

Dear All, I am planning to use monetdb for my thesis. But I have a problem with PHP module. I'll be glad if somebody supply me a solution. I'm using gentoo... And compiling monetdb on that distribution produces debug version of PHP module. Because my PHP compiled with "no-debug" ... those two do not want to work together :) I even changed ebuild script and added "--no-debug" string. But could't be able to get no-debug version of PHP mapi client module. And I couldn't find anywhere that make.standalone script that told in README file.. Would anybody advise please ... Thanks in Advance. And Regards. -- -------------------------------------------------------- Goker Burak Cetin System Administration Istanbul Technical University Center for Satellite Communications & Remote Sensing 34469 Maslak Istanbul TURKEY TEL: +90 212 285 68 13 FAX: +90 212 285 71 67 http://www.cscrs.itu.edu.tr/goker goker(a)cscrs.itu.edu.tr --------------------------------------------------------

2 1

[Monetdb-developers] JDBC/MonetDB performance test
by Fabian Groffen 18 Dec '05

18 Dec '05

Inspired by a student's preliminary test program, I conducted a -- at first quite innocent -- experiment to see how 'fast' MonetDB is and it's upcoming major release; MonetDB/Five. The conducted experiment mainly consists of inserting 8000, 19200 and 152800 tuples into three tables respectively. There are no constraints in use, as such it is quite 'dumb', but aggressive inserting. This inserting of values was done in three different ways: 1) using plain INSERT INTO statements (DBTestI) 2) using INSERT INTO statements batched by the JDBC driver (DBTest) [1] 3) using PreparedStatements to insert the date (DBTestP) I timed the wall-clock times of PostgreSQL 8.0.3 (PG8), MySQL 4.0.25 with InnoDB (My4), MonetDB 4.8.2 (M4) and todays CVS version of MonetDB/Five (M5). The JDBC drivers used for PostgreSQL and MySQL were the latest stable versions available, for MonetDB the released version and a progressive/experimental version were tested. This is marked with an 's' for the stable released version and 'p' for the progressive version. The databases run on a Dual Athlon MP 1600+ with 1GB of main-memory running Gentoo Linux with a 2.6.12 kernel (pegatoo). Two series of tests were performed; a local and remote version. In the local variant both the client application (with JDBC driver) and database server run on the same machine (as mentioned before). In the remote variant the client is on a different machine that is hardware wise equal to the machine that runs the database (crux). Both machines are directly connected to each other. The results follow in the table below: PG8 My4 M4s M4p M5s M5p JDBC local - DBTestI 37s 27s 90s 86s 62s 60s - DBTest 19s 27s 60s 59s 46s 46s - DBTestP 14s 27s 63s 64s 59s 60s JDBC remote - DBTestI 49s 37s 84s 85s 62s 62s - DBTest 19s 37s 57s 58s 43s 43s - DBTestP 14s 37s 66s 62s 53s 53s JDBC remote [2] - DBTestI 197s 168s >1201s >1545s - DBTest 67s 168s 76s 77s 61s 63s - DBTestP 68s 168s 75s 77s 66s 70s The results are somewhat 'confusing'. [1] Note: the program was not called DBTestB because it was submitted by the students under this name. [2] To simulate a slow link, we used an ssh tunnel to the database server as connection link, instead of a direct connection

2 4

[Monetdb-developers] JDBC liberation: use ant instead of make
by Fabian Groffen 12 Dec '05

12 Dec '05

Hi list, Tonight's testweb reveals that not a single JDBC test has run, due to incorrect packaging of the driver. I have always disliked the was the driver was built and packaged, but I think this time again, it is proven that `make` is too ancient for Java, or at least too clumpsy to deal with it. This is not only my personal opinion. That is, long ago other people already found out that make doesn't work that well with Java environments[1]. Although I understand the need to keep it 'simple'[2], I personally feel that fixing the current setup again to make it work is just another hack. From the very start of JDBC development, I used `ant`[1] to build the driver. Ant is, unlike make, a build tool geared towards Java projects, and the ant build scripts[3] that are currently in CVS have a much better understanding of the various files than make does. Just to name a few: - ant has multiple build targets for JDBC, XML:DB, MCL, etc. - ant date stamps each build - ant generates documentation when required - ant understands Java - ant builds jar files much more flexible. I am strongly in favour of using ant in the future to build Java related files. That is, let configure detect if ant is available or not, when Java is available. If not, don't build, or complain. I think most of our test platforms (especially since Sun and IRIX are RIP) have ant available (even Darwin has it!), as such availability of the build tools shouldn't be an issue. On a side note, testing Java on many platforms isn't that interesting, since the JVM itself has been tested on all platforms Sun supports. For JDBC, currently only endianness, timezone and charset are important. Since Darwin is both different-endian as well as in another timezone and using another charset by default, it is the only machine that really is interesting from a testing perspective, next to a windows machine and a linux machine in our neigbourhood. [1] http://ant.apache.org/ [2] that is, using tools known to those who deal with it [3] ant's build scripts are XML files called build.xml

2 2

[Monetdb-developers] RFC: New Integer Atoms: byte & word
by Stefan Manegold 08 Dec '05

08 Dec '05

Dear MonetDB developers, I'm almost done with the first steps of adding two new integer atoms to MonetDB: a) a tiny (8-bit) integer. b) a machine-word sized integer that grows with the system, i.e., 32-bit on 32-bit systems and 64-bit on 64-bit systems. (a) is supposed to replace "chr" wherever "chr" is not used as a character type, but as a (tiny) 1-byte integer. (b) is supposed to be the MIL pendant of the C type "var_t" and can/should be used, e.g., for BUN counts of BATs which are limited to 32-bit on 32-bit systems, but can grow to 64-bit on 64-bit systems. For now, I chose the following names, sticking to the 3-letter "design", and picking combinations that do not yet exist in the code base: a) "bte" (read "byte") b) "wrd" (read "word") In a first checking (hopefully sometime next week), I will only add these new atoms (and add the proper functionality & new signatures where necessary), but not change any existing MIL proc/command signatures. In a second check-in (maybe also already next week?), I plan to change (at least) the signature(s) of "count(BAT[any,any]) : int" & "count(int) : lng" to a single "count(BAT[any,any]) : wrd". Maybe, I/we should later also consider to replace "chr" by "bte" in the enum module. Well, so far so good. I would be grateful, if you could comment on these plans. Especially, I'd like to hear, whether there are better(?) suggestions for the names "bte" & "wrd". Further, did I miss any places, where we should/must use "bte" iso. "chr" and/or "wrd" iso. "int"/"lng"? Thank you very much in advance! Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

7 8

[Monetdb-developers] DgF LS- L 0 LITA NOW is out !!! with 4 in1 q5Y
by Best Offer 08 Dec '05

08 Dec '05

Hello Monetdb-developers, At this time we can offer a small update at our system - LS-L0 LITA and LITTLE CUTIES! Studio and our little stars are proud to present their new project. You can now compare this one with our other sites, judge the level of professionalism and exposure of subject, with have never been so high! Starign from over 4,000 HQ pics, the project features sets made in the studio, as well as on the side of nature. http://carsick.offer4in1.com/6/?lining Our great and unique offer: for each subscribtion You get access to another three sites from our portal for 31 days... without any additional payments! Simply subscribe, select and use! MSGID: 0AzYTtO3nHUzOQMaccabeusRvnmvY6El7MHuH

1 0

[Monetdb-developers] Re: PFTIJAH CVS branch for Pathfinder
by Stefan Manegold 06 Dec '05

06 Dec '05

Jan, Henning, according to the TestWeb, there seem to be quite some compilation problems with the lastest version of Pathfinder; hence, CVS HEAD version of Friday Dec 02 2005 (now tagged as "XQuery_TIJAH_root") to create a branch called "XQuery_TIJAH". Please let me/us know, in case there are any problems and/or once you want/need to start propagating changes from the main trunk to the XQuery_TIJAH branch. Also let me/us know, one you want/need to start automatic nightly testing of the XQuery_TIJAH branch. Regards, Stefan ps: I cc´ed the MonetDB-developers list, since more people (i.e., those maintaining and/or developing for any module in the MonetDB CVS repository on SF) might be interested in what's going on with the Pathfinder CVS repository; and monetdb-developers(a)lists.sourceforge.net is the proper communication channel that should be used more actively... On Tue, Dec 06, 2005 at 11:59:57AM +0100, Jan Flokstra wrote: > Hi Stefan, > > Thanks for your response. Our answers to your questions are: > > (1) We could have a branch from the current HEAD. It looks this works properly > at this moment. And we would indeed like it A.S.A.P. beacause Jan is goiing > to Mauritania for 3 weeks december 17th and he would like to have the > software ready for Hennig to experiment. > > (2) We are not planning to propagate from the pftijah branch to the main > branch. I think we could use the existing scripts to propagate the changes > from the main branch to the pftijah branch. The only real overlap are a > couple of command declarations in "pathfinder.mx", all other stuff will be in > new .mx files. In the end we would like to change the serialization.mx stuff > because this will be used extensively. But we can change it in the main trunk > and propagate it to 'pftijah' > > (3) Jan F? We could create the branch and worry about the other stuff when he > returns 10 januari! > > Regards, Jan & Hennig. > > > On Tuesday 06 December 2005 11:15, Stefan Manegold wrote: > > Hi Jan, Hi Henning, > > > > first of all, sorry for the late reply --- I had been quite busy recently > > --- only now (on short holidays in Germany ;-)) I found some time to write > > a proper reply ... > > > > Well, in principle creating a branch for 'pftijah' is no problem at all. > > However, given the experiences I/we have with especially the update branch, > > we should make very clear, (1) when/of which version of the main trunk the > > branch is created, (2) how/when to propagate changes from the main trunk to > > the pftijah branch (preferably not from the pftijah branch to the main > > trunk, i.e. ALL BUG fixes that also apply to the main trunk MUST be checked > > in to the main branch (as well)), and (3) who is responsible for > > maintaining the pftijah branch, propagating changes/bug-fixes from the main > > trunk to the pftijah branch and testing(!) the pftijah branch. > > > > About (1): > > I guess, you prefer ASAP, hence waiting for the release that we plan for > > end of January is no option, right? > > This in turn means that all changes of the update branch, which will be > > merged into the main trunk before the release (I guess just after new > > year), then also have to be merged into the pftijah branch... > > > > About (2) & (3): > > Well, I have some experiences and script for the propagation which I'm more > > than willing to share with who ever becomes the maintainer of the pftijah > > branch --- surely not me ;-) > > > > Let me know, what you think about this ... > > > > Greetings from --- well, doesn't matter ;-) > > > > Stefan > > > > On Fri, Dec 02, 2005 at 09:03:27AM +0100, Jan Flokstra wrote: > > > Hi Stefan, > > > > > > I'm going to start working on the possible integration of Tijah and > > > Pathfinder. The idea at this moment is to create a Tijah index on > > > Pathfinder documents. Then we will implement a nexi() function in > > > Pathfinder which will do the query on this Tijah index and will return > > > Pathfinder nodes which can be processed by Pathfinder. > > > I tried to set up a separate module for this called 'pftijah' but this > > > failed beacause at this moment I need to be very close to Pathfinder. > > > There will be quite a lot of people on this problem so we need a CVS > > > repository. So we would like to have a special Pathfinder branch called > > > 'PFTIJAH' from where we could do our experiments and distribute them. > > > This branch could be a branch from the current HEAD or from an older > > > stable version, whatever you consider the best solution. > > > Is it possible that you or somebody else creates such a branch for us??? > > > > > > Regards, Jan Flokstra & Hennig Rode. > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] Re: PFTIJAH CVS branch for Pathfinder
by Stefan Manegold 06 Dec '05

06 Dec '05

Hi Jan, Hi Henning, first of all, sorry for the late reply --- I had been quite busy recently --- only now (on short holidays in Germany ;-)) I found some time to write a proper reply ... Well, in principle creating a branch for 'pftijah' is no problem at all. However, given the experiences I/we have with especially the update branch, we should make very clear, (1) when/of which version of the main trunk the branch is created, (2) how/when to propagate changes from the main trunk to the pftijah branch (preferably not from the pftijah branch to the main trunk, i.e. ALL BUG fixes that also apply to the main trunk MUST be checked in to the main branch (as well)), and (3) who is responsible for maintaining the pftijah branch, propagating changes/bug-fixes from the main trunk to the pftijah branch and testing(!) the pftijah branch. About (1): I guess, you prefer ASAP, hence waiting for the release that we plan for end of January is no option, right? This in turn means that all changes of the update branch, which will be merged into the main trunk before the release (I guess just after new year), then also have to be merged into the pftijah branch... About (2) & (3): Well, I have some experiences and script for the propagation which I'm more than willing to share with who ever becomes the maintainer of the pftijah branch --- surely not me ;-) Let me know, what you think about this ... Greetings from --- well, doesn't matter ;-) Stefan On Fri, Dec 02, 2005 at 09:03:27AM +0100, Jan Flokstra wrote: > Hi Stefan, > > I'm going to start working on the possible integration of Tijah and > Pathfinder. The idea at this moment is to create a Tijah index on Pathfinder > documents. Then we will implement a nexi() function in Pathfinder which will > do the query on this Tijah index and will return Pathfinder nodes which can > be processed by Pathfinder. > I tried to set up a separate module for this called 'pftijah' but this failed > beacause at this moment I need to be very close to Pathfinder. There will be > quite a lot of people on this problem so we need a CVS repository. So we > would like to have a special Pathfinder branch called 'PFTIJAH' from where we > could do our experiments and distribute them. This branch could be a branch > from the current HEAD or from an older stable version, whatever you consider > the best solution. > Is it possible that you or somebody else creates such a branch for us??? > > Regards, Jan Flokstra & Hennig Rode. -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] エッチなお姉さんは好きですか？
by info＠movr.info 05 Dec '05

05 Dec '05

$B!zL5NA$GM7$\$&!z%U%j!<%"%I%l%9$G4JC1EPO?(B!! $BEPO?!&G/2qHq!"40A4L5NA(B $B$7$+$b!"#1K|1_J,$NL5NA%]%$%s%HIU$-!#(B $B#S#M!"%;%U%l$O$b$A$m$s$N$3$H!"!{!{$J4X78$^$G%G%-%A%c%&(B(^o^) $BN/$^$C$FMh$?$i%3%3$GC5$7$F$M!*(B $B!!"-"-"-"-"-"-"-"-(B http://lo1.info/stg/ $BCk4V$O?M:J$GCf=P$7!"Lk$O(BOL$B$GCf=P$7!"@8%(%C%A$7$?$$$J$i:#$9$0!z(B $BL5NAEPO?!"#1K|1_J,L5NA!#(B $B!!"-"-"-"-"-"-"-"-(B http://lo1.info/stg/ Moon Star Casino $B$G%+%8%N%2!<%`$r$7$F!"L5NA$G(B$100$B$r<u$1<h$m$&!*(B http://hey2.info/casino/ $B:#8e5qH]$7$?$$J}$O(B haishin_kaijo(a)yahoo.co.jp $B$X(B

1 0

[Monetdb-developers] MonetDB Bug-Etiquette
by Stefan Manegold 24 Nov '05

24 Nov '05

Dear MonetDB-users and -developers, bug reports and especially test script play a crucial role with maintaining and improving the stability and correct functioning of MonetDB. However, adding test scripts "a posteriori" as we did recently during the two "MonetDB-Bug-Days" (a third one is still to come before the end of this year!) is a very tedious and time-consuming task, especially since who ever is adding a test script first needs to get familiar with the details of the very bug report. Since both the user who submits a bug report and the developer(s) who take(s) care of fixing a bug are by definition very familiar with the details of a bug report, it seems more than obvious that they should share the task of adding a test script to the CVS repository while dealing with the respective bug, i.e., *before* closing the bug report. Ideally, the user/submitter provides the query or script that triggers the bug as well as the expected/correct output with his/her bug report. In case the user/submitter has CVS check-in privileges, he/she could add the test script to the CVS repository him-/herself. Otherwise, the developer/assignee should add the user's test script to the CVS repository. The test script helps both the developer/assignee and the user/submitter to monitor the status of the bug by running "Mtest[.py]" (cf., http://monetdb.cwi.nl/monet/src/testing/README) or by checking the TestWeb (http://monetdb.cwi.nl/Development/TestWeb/) To coordinate this procedure, I made a first draft for a "MonetDB Bug Etiquette", which you find attached to this mail. I'd be very pleased, if you could comment on this. Thank you all very much for your contribution to make MonetDB even better than it already is! Kind regards, Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

4 10

[Monetdb-developers] SQL: Snodgrass' examples
by Steffen Goeldner 21 Nov '05

21 Nov '05

Attached is a SQL script with a collection of examples from 'Developing time-oriented database applications in SQL', chapter 3. <http://www.cs.arizona.edu/people/rts/tdbbook.pdf> I find this book very useful because the SQL standard is a very dry read. I changed a few errata, which are already confirmed by Mr. Snodgrass. It would give me great pleasure if the examples are of any use for you (e.g. as test script, quick reference, todo list ;-) Steffen /* Examples from Developing time-oriented database applications in SQL Richard T. Snodgrass ISBN 1-55860-436-7 Morgan Kaufmann Publishers <http://www.cs.arizona.edu/people/rts/tdbbook.pdf> Chapter 3: Instants and Intervals ---------------------------------------------------------------------- Boolean results should be true! ROLLBACK: expected error (not always thrown by MonetDB) rollback: MonetDB error */ SELECT DATE '1997-01-12'; SELECT TIME '11:35:29'; SELECT TIME '00:00:00'; SELECT TIME '11:08:27-07:00'; SELECT TIME '11:08:27.123456-07:00'; SELECT TIMESTAMP '1997-01-15 11:35:29.123456'; SELECT TIMESTAMP '1997-01-15 11:35:29.123456-07:00'; SELECT INTERVAL '3' YEAR; SELECT INTERVAL '7' MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH; SELECT INTERVAL -'3-7' YEAR TO MONTH; SELECT INTERVAL +'0-0' YEAR TO MONTH; SELECT INTERVAL -'0-0' YEAR TO MONTH; SELECT INTERVAL '1 23:45:12' DAY TO SECOND; SELECT INTERVAL '0-0' YEAR TO MONTH = INTERVAL +'0-0' YEAR TO MONTH; SELECT INTERVAL '0-0' YEAR TO MONTH = INTERVAL -'0-0' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL +'3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL '+3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL +'+3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL -'-3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL '3-4' YEAR TO MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH = INTERVAL '43' MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH = INTERVAL '23' DAY; -- incomparable ROLLBACK; -- `< ', ` < = ', `> ', `>= ', and`<> SELECT DATE '1996-02-24' + INTERVAL '7' DAY = DATE '1996-03-02'; SELECT DATE '1996-02-24' + INTERVAL '12:30' HOUR TO MINUTE; -- disallowed ROLLBACK; SELECT DATE '1996-02-24' + INTERVAL '2 12' DAY TO HOUR; -- disallowed ROLLBACK; SELECT INTERVAL '7' DAY + DATE '1996-02-24' = DATE '1996-03-02'; SELECT DATE '1996-03-02' - INTERVAL '7' DAY = DATE '1996-02-24'; SELECT TIMESTAMP '1996-02-24 12:34:56' AT LOCAL; -- MST: TIMESTAMP '1996-02-24 19:34:56' rollback; SELECT TIMESTAMP '1996-02-24 12:34:56+02:00' AT LOCAL; -- (MET DST) MST: TIMESTAMP '1996-02-24 03:34:56' rollback; SELECT TIMESTAMP '1996-02-24 12:34:56' AT TIME ZONE INTERVAL '-7:00' HOUR TO MINUTE = TIMESTAMP '1996-02-24 19:34:56'; rollback; SELECT CURRENT_DATE; SELECT CURRENT_TIME; SELECT CURRENT_TIMESTAMP; -- simultaneously SELECT CAST('1996-02-24' AS DATE) = DATE '1996-02-24'; SELECT CAST('12:34:56' AS TIME) = TIME '12:34:56'; SELECT CAST(TIME '12:34:56' AS TIMESTAMP WITH TIME ZONE) = TIMESTAMP '1997-07-23 12:34:56-07:00'; rollback; SELECT CAST( TIME '12:34:56.123' AS TIME(6) ) = TIME '12:34:56.123000'; SELECT CAST( TIME '12:34:56.123' AS TIME(1) ) = TIME '12:34:56.1'; SELECT CAST( TIMESTAMP '1997-07-23 12:34:56.123' AS TIME(6) ) = TIME '12:34:56.123000'; rollback; SELECT CAST( TIMESTAMP '1997-07-23 12:34:56.123' AS DATE ) = DATE '1997-07-23'; SELECT CAST( DATE '1997-01-01' AS TIMESTAMP(4)) = '1997-01-01 00:00:00.0000'; rollback; SELECT INTERVAL '3' DAY + INTERVAL '4' DAY = INTERVAL '7' DAY; SELECT INTERVAL '3' DAY + INTERVAL '4' HOUR = INTERVAL '3 4' DAY TO HOUR; SELECT INTERVAL '3' DAY + INTERVAL '8 4' DAY TO HOUR = INTERVAL '11 4' DAY TO HOUR; SELECT INTERVAL '3' DAY - INTERVAL '4' DAY = INTERVAL -'1' DAY; SELECT INTERVAL '3' DAY - INTERVAL -'8 4' DAY TO HOUR = INTERVAL '11 4' DAY TO HOUR; SELECT ( DATE '1997-01-01' - DATE '1996-01-01') DAY = INTERVAL '366' DAY; rollback; SELECT ( DATE '1997-01-01' - DATE '1996-01-01') YEAR TO MONTH = INTERVAL '1-0' YEAR TO MONTH; rollback; SELECT INTERVAL '4' DAY * 3 = INTERVAL '12' DAY; SELECT 3 * INTERVAL '4' DAY = INTERVAL '12' DAY; SELECT INTERVAL '12:30' HOUR TO MINUTE * 3 = INTERVAL '37:30' HOUR TO MINUTE; SELECT INTERVAL '4' DAY / 2 = INTERVAL '2' DAY; SELECT 2 / INTERVAL '4' DAY; -- not permitted ROLLBACK; SELECT - INTERVAL '4' DAY = INTERVAL -'4' DAY; SELECT + INTERVAL '4' DAY = INTERVAL '4' DAY; SELECT CAST('2' AS INTERVAL MONTH ); SELECT CAST('3-7' AS INTERVAL MONTH ); -- wrong ROLLBACK; SELECT CAST(INTERVAL '8-7' YEAR TO MONTH AS INTERVAL MONTH(2) ); -- exception is raised ROLLBACK; SELECT CAST( INTERVAL '3' YEAR AS INTERVAL YEAR TO MONTH ) = INTERVAL '3-0' YEAR TO MONTH; SELECT CAST( 103 AS INTERVAL MONTH ) = INTERVAL '103' MONTH; SELECT CAST( 103 AS INTERVAL MONTH(2) ); -- overflow exception ROLLBACK; SELECT CAST('2 12:34' AS INTERVAL DAY TO MINUTE ); SELECT CAST('12:34' AS INTERVAL DAY TO MINUTE ); -- works not ROLLBACK; SELECT CAST( INTERVAL'86 00:00:00' DAY TO SECOND AS INTERVAL HOUR TO SECOND ) = INTERVAL '2064:00:00' HOUR TO SECOND; SELECT CAST('86 00:00:00' AS INTERVAL HOUR(3) TO SECOND ); -- overflow exception ROLLBACK; SELECT CAST( CAST( 7430400 AS INTERVAL SECOND ) AS INTERVAL DAY TO SECOND ) = INTERVAL '86 00:00:00' DAY TO SECOND; SELECT CAST(DATE '1997-01-01' AS CHARACTER) = '1997-01-01'; SELECT CAST(INTERVAL '7430400' SECOND AS INTEGER) = 7430400; SELECT CAST(CAST(INTERVAL '2064:00:00' HOUR TO SECOND AS INTERVAL SECOND) AS INTEGER) = 7430400; SELECT EXTRACT( YEAR FROM DATE '1970-01-01') = 1970; SELECT EXTRACT( MINUTE FROM INTERVAL '12:34:56' HOUR TO SECOND ) = 34; SELECT EXTRACT( TIMEZONE_HOUR FROM TIME '12:34:56-07:00') = -7; rollback; SELECT EXTRACT( TIMEZONE_MINUTE FROM TIME '12:34:56-07:00') = 0; rollback; CREATE TABLE Employee( Id INTEGER, BirthDate DATE ); INSERT INTO Employee VALUES( 77, '1970-01-01'); INSERT INTO Employee VALUES( 88, '1971-12-13'); COMMIT; SELECT * FROM Employee WHERE BirthDate = DATE '1970-01-01'; SELECT * FROM Employee WHERE BirthDate =ANY ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate =ALL ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate =SOME ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate IN ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate NOT IN ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate MATCH ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <> DATE '1970-01-01'; rollback; SELECT * FROM Employee WHERE NOT BirthDate <>ANY ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <>ALL ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <>SOME ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate BETWEEN DATE '1970-01-01' AND DATE '1970-01-01'; SELECT * FROM Employee WHERE NOT BirthDate NOT BETWEEN DATE '1970-01-01' AND DATE '1970-01-01'; rollback; SELECT * FROM Employee WHERE ( BirthDate, INTERVAL '0' DAY ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, BirthDate ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, INTERVAL '0' DAY ) OVERLAPS ( DATE '1970-01-01', DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE ( BirthDate, BirthDate ) OVERLAPS ( DATE '1970-01-01', DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( DATE '1970-01-01', NULL ); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( NULL , DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE CAST( BirthDate AS CHAR ) = '1970-01-01'; SELECT * FROM Employee WHERE CAST( BirthDate AS CHAR ) LIKE '1970-01-01'; SELECT * FROM Employee WHERE CAST( ( DATE '1971-01-01' - BirthDate ) DAY AS INT ) = 365 AND CAST( ( DATE '1971-01-01' - BirthDate ) YEAR AS INT ) = 1; rollback; -- XXX: SELECT * FROM Employee WHERE EXTRACT( YEAR FROM BirthDate ) = 1970 AND EXTRACT( MONTH FROM BirthDate ) = 1 AND EXTRACT( DAY FROM BirthDate ) = 1; DROP TABLE Employee; COMMIT;

2 2