September 2006 - developers-list

[Monetdb-developers] configure & *_config.h include files
by Stefan Manegold 01 Dec '06

01 Dec '06

Dear fellow developers, while trying to fix portability issues with the pftijah modules of pathfinder, I noticed the following problem: To ensure portability, each source file should know about and adhere to what configure found out; hence, the respective X_config.h (with X one of monetdb, sql, pf, etc,) must be the first include in each .c file. However, with the front-ends, some files (especially those implementing extension modules) also need to MonetDB's monet.h or gdk.h to get the respective definition. Since monet.h includes gdk.h which includes monet_utils.h which in turn includes monetdb_config.h, these files the include both the "local" X_config.h (with X one of sql, pf, etc,) and the monetdb_config.h. This might trigger two problems: 1) If we compile sql, pf, etc, a against a binary install of MonetDB which was configured and generated on an binary compatible but potentially (slightly) differently configured/installed system, this might lead to conflicting definition/declarations in the two X_config.h. 2) Even if we compile MonetDB and the front-end on the same system, there might be conflicts since the respective configure are not completely identical. In pathfinder/runtime we avoid (2) be not including pf_config.h but only monetdb_config.h (via monet.h or gdk.h) which might actually lead to problems similar to (1). In pathfinder/module/pftijah, we run into (2) with _FILE_OFFSET_BITS (at least) on our Solaris 10 x86 machine, since only MonetDB' configure.ag checks AC_SYS_LARGEFILE() while pathfinder's configure.ag does not. To solve the problem (2) "properly", we could either make all configures identical (e.g., by moving all "local" checks from the various configure.ag to MonetDB/conf.monet.m4). But that still leaves us with (1). To solve (1) (and (2)) "properly", we could avoid the implicit inclusion of monetdb_config.h in monet_utils.h (and hence gdk.h & monet.h) by removing the respective include from monet_utils.h. But then, we'd have to explicitly include monetdb_config.h in each .c file that now includes one of monet_utils.h, gdk.h, monet.h (directly or via some other include) --- a lot of work, with a high risk to overlook some locations... A "better"(?) (at least simpler) solution could be to guard the #include "monetdb_config.h" in MonetDB' monet_utils.h by, say, #ifndef NO_MONETDB_CONFIG ... #endif, and then define NO_MONETDB_CONFIG in X_config.h (with X one of sql, pf, etc,). I'd strongly vote for the last solution. ;-) Comments, ideas, complaints, objections? 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 7

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 4, Issue 13
by p.a.boncz 26 Sep '06

26 Sep '06

Hi Jens, I read your recursion proposal, but I do not really understand the need or goal for such a syntax extension: - is't the default XQuery function recursion more powerful? - why not confine oneself to have an *internal* algebraic closure operator, if that is such a useful abstraction? Nor do I understand the need for the focus on nodes and set fixpoint semantics. If the result expression is a sequence of nodes you may define this to be duplicate-free and in document order, but it is less obvious why atomic sequences should be treated like that. Order is a first-class citizen in XQuery, and atomic types are also first-class. And what about element construction? Isn't it obvious given the recursive nature of XML that people may want to build XML documents with recursion -- so the choice to union all results always is limiting. I can imagine that *some* XQuery recursion patterns could be translated to this fixpoint operator. Tail recursion is the big "success story" here (given your node-union fixpoint semantics it will actually only be possible in rare cases). However, given the fact that XQuery has for-loops, it is quite unlikely in the first place that in the real world people will use tail-recursion for iteration (this may distinguish XQuery from "purer" functional languages). I conclude that this extension per-se does not help in translating recursion in XQuery for the algebra backend at all (nor is it its goal), rather places a second recursive vehicle beside it. I am completely puzzled to hear such proposals from the usually XQuery-standard-respecting community in Garching. Finally, what exactly is "hacky" about the milprint_summer recursion approach? Maybe you mean with "hacky" that it does not try to eliminate recursion, and thus only works if the target language offers recursion. The reality is that only trivial recursion patterns can be eliminated, so this limitation will apply always. And you may forget, that a lot of recursion in milprint_summer *is* eliminated, as all calls inside a for-loop are reduced to one thanks to "loop-lifting" (maybe we could even "sell" this idea in the FP community). So actually it surely is not as primitive/hacky as the implementation of recursion in say Galax. Defining myself as an engineer, I am aware of the limitations of my knowledge and understanding of such formal issues. ready to be educated.. Peter -----Original Message----- From: monetdb-developers-bounces(a)lists.sourceforge.net [mailto:monetdb-developers-bounces@lists.sourceforge.net] On Behalf Of monetdb-developers-request(a)lists.sourceforge.net Sent: Saturday, September 23, 2006 12:14 AM To: monetdb-developers(a)lists.sourceforge.net Subject: Monetdb-developers Digest, Vol 4, Issue 13 Send Monetdb-developers mailing list submissions to monetdb-developers(a)lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/monetdb-developers or, via email, send a message with subject or body 'help' to monetdb-developers-request(a)lists.sourceforge.net You can reach the person managing the list at monetdb-developers-owner(a)lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Monetdb-developers digest..." Today's Topics: 1. Upcoming feature: Recursion in Pathfinder (algebra) (Jens Teubner) 2. configure & *_config.h include files (Stefan Manegold) 3. Re: configure & *_config.h include files (Stefan Manegold) 4. Error with the Java Client (Jim Foley) 5. Re: Error with the Java Client (Fabian Groffen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 Sep 2006 14:11:03 +0200 From: Jens Teubner <jens.teubner(a)in.tum.de> Subject: [Monetdb-developers] Upcoming feature: Recursion in Pathfinder (algebra) To: monetdb-developers(a)lists.sourceforge.net Cc: Loredana Afanasiev <lafanasi(a)science.uva.nl> Message-ID: <20060922121103.GF11762(a)notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii Hi all, this is to keep you informed what we are currently working on in Munich. Pathfinder's purely relational approach so far cannot handle *recursion* in XQuery expression in a sensible way (recursion in the W3C XQuery language is possible by means of user-defined recursive function). The milprint_summer branch includes some hacky implementation (with help of MIL PROCs) that provides recursion nevertheless. Together with people from UVA (Loredana Afanasiev in particular), we are currently working on support for recursion in an algebraic manner. A generic handling of recursion seems quite difficult. The W3C XQuery language syntax does not pose any restrictions on the style of recursion that can be described. The common approaches to deal with recursion in relational systems, in contrast, cannot cope with all these variants of recursion. A second problem is that the kind of recursion used in a given query (e.g., tail recursion) used in a given query seems quite tricky to infer (and a consistent treatment of this case in the algebraic compiler adds another challenge). Hence, we decided to go for a limited recursion feature in Pathfinder first. We may later on try to add a more generic handling. We are currently implementing a *syntax extension* to Pathfinder that allows to describe a limited notion of recursion. The new construct with $var seeded by expr1 recurse expr2 will have the following semantics: 1. expr1 is evaluated once and then used as a seed to initiate the recursion. $var is bound to the result of expr1 in the first recursion step. 2. Then, expr2 is evaluated over and over. Variable $var is visible in expr2 and for each recursion step will be bound to the union of all items (nodes) obtained in the previous recursion steps. (The results of all recursion steps are collected into the overall result using set semantics.) 3. Recursion terminates if a recursion step does not contribute any new items (nodes) to the overall result (i.e., we reached a fixpoint). (Remark: There still is some discussion if (for performance reasons) each recursion step should only observe the *new* items obtained in the previous recursion step, or whether the entire result set collected so far should be observable in expr2.) The `union' semantics of this new recursion construct implies that we can do recursion only on *nodes*, not on atomic values. This quite directly matches the requirements of the UVA group (and others) that are looking for a "transitive closure" operator. Note that the above syntax extension that we are about to introduce does not interfere with any existing constructs. So our changes will not affect any (existing) valid XQuery expression. Motivation: There is a high demand for transitive closure functionality in the group at UVA (i.e., Loredana and others), but also in other research groups (as I was told). Transitive closure is, e.g., a vital component of an XPath dialect known as "Regular XPath". Regards from Garching Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Software is like sex: It's better when it's free -- Linus B. Torvalds

3 4

[Monetdb-developers] Compilation warnings MonetDB/SQL
by Fabian Groffen 25 Sep '06

25 Sep '06

For what it is worth, here is a list of warnings produced when compiling MonetDB/SQL. MonetDB itself appears to be mostly warning free. Making and installing MonetDB/SQL in /ufs/fabian/scratch/vtmp/build-current-monetdb-pegasus.ins.cwi.nl/sql /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_delete': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:223: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_check': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:266: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'schema_get_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:1177: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_kc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4069: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_key': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4084: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_ic': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4113: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_idx': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4128: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_tc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_trigger': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4165: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_column': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4187: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4240: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_func': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4264: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4265: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_drop_schema': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4413: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_null': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4717: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_default': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4741: warning: comparison between signed and unsigned sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx: In function 'sql_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx: In function 'scanner_string': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx:562: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx: In function 'rel_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx:2878: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:252: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:269: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:286: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_3': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:322: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'backend_dumpstmt_': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:371: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:377: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:392: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:407: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:417: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:427: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:821: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:834: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:850: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:856: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:873: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:876: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:946: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:966: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:972: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:975: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1032: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1042: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1081: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1149: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1153: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1155: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1157: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1160: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1260: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1283: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1301: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1351: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1416: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx: In function 'convert2str': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx:564: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c: In function 'ODBCFetch': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1133: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1418: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c: In function 'SQLConnect_': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:93: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:111: warning: comparison between signed and unsigned

2 2

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 24 Sep '06

24 Sep '06

> Date: Sat, 23 Sep 2006 09:56:44 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: <20060923075643.GB21350(a)cwi.nl> > Content-Type: text/plain; charset=utf8 > > On 22-09-2006 23:44:20 -0400, Jim Foley wrote: > > Fabian, > > > > I can accept that my transaction is invalid and there is no way to > > tell what the state of tables/object is but I cannot except that a > > fatal java exception is what is expected. I would expect a > java error > > stating that the state of the database is unknown and > please roll back > > the last transaction. > > > > Am I expecting too much from open software? > > No, I just never tried doing this. I just fixed this in CVS, thanks. Thank you, Fabian. I will download the new code and try it out. Hopefully once I get to know the code better I will be able to help you out with some of these problem. Jim

1 0

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 23 Sep '06

23 Sep '06

Fabian, I can accept that my transaction is invalid and there is no way to tell what the state of tables/object is but I cannot except that a fatal java exception is what is expected. I would expect a java error stating that the state of the database is unknown and please roll back the last transaction. Am I expecting too much from open software? Jim > Message: 5 > Date: Fri, 22 Sep 2006 16:57:03 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > > Hi Jim, > > On 22-09-2006 10:47:13 -0400, Jim Foley wrote: > > voc-> start transaction; > > Operation successful > > > > auto commit mode: off > > voc-> select * from tables; > > Error: SELECT: no such table 'tables' > > Your transaction died here ... > > > voc-> > > voc-> create table test > > voc=> (id int, jimnum decimal(38,2)); > > Error: current transaction is aborted (please ROLLBACK) > > ... hence the error message you need to rollback > > > voc-> \d > > A fatal exception occurred: java.sql.SQLException: current > transaction > > is aborted (please ROLLBACK) > > This might be a bit hefty, but in fact is expected behaviour, > since your transaction has been invalidated, so it is unknown > what tables/objects there should be at this moment. > > > > ------------------------------ >

2 1

[Monetdb-developers] Error with the Java Client
by Jim Foley 22 Sep '06

22 Sep '06

I am doing some testing with MonetDB and the java client. I have a repeatable error that I am not sure if it is a but or the way I am using the tool. I have an Oracle background so it could be me. Java client connection on Windows 2000 Professional to MonetDB on openSuSe 10.1 using SQL. Thanks for your help. Jim Foley C:\MonetDB Client>java -jar jdbcclient-1.4.jar -h 192.168.1.101 -d demo -u voc password: Welcome to the MonetDB interactive JDBC terminal! Database: MonetDB 4.13.1 Driver: MonetDB Native Driver 1.4 (Dilate 20060918) Type \q to quit, \h for a list of available commands auto commit mode: on voc-> \d voc-> start transaction; Operation successful auto commit mode: off voc-> select * from tables; Error: SELECT: no such table 'tables' voc-> voc-> create table test voc=> (id int, jimnum decimal(38,2)); Error: current transaction is aborted (please ROLLBACK) voc-> \d A fatal exception occurred: java.sql.SQLException: current transaction is aborted (please ROLLBACK) java.sql.SQLException: current transaction is aborted (please ROLLBACK) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConne ction.java:2292) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.processQuery(MonetConne ction.java:2045) at nl.cwi.monetdb.jdbc.MonetStatement.internalExecute(MonetStatement.java:3 57) at nl.cwi.monetdb.jdbc.MonetStatement.execute(MonetStatement.java:326) at nl.cwi.monetdb.jdbc.MonetStatement.executeQuery(MonetStatement.java:390) at nl.cwi.monetdb.client.JdbcClient.processInteractive(JdbcClient.java:646) at nl.cwi.monetdb.client.JdbcClient.main(JdbcClient.java:476) C:\MonetDB Client>

2 1

[Monetdb-developers] Upcoming feature: Recursion in Pathfinder (algebra)
by Jens Teubner 22 Sep '06

22 Sep '06

Hi all, this is to keep you informed what we are currently working on in Munich. Pathfinder's purely relational approach so far cannot handle *recursion* in XQuery expression in a sensible way (recursion in the W3C XQuery language is possible by means of user-defined recursive function). The milprint_summer branch includes some hacky implementation (with help of MIL PROCs) that provides recursion nevertheless. Together with people from UVA (Loredana Afanasiev in particular), we are currently working on support for recursion in an algebraic manner. A generic handling of recursion seems quite difficult. The W3C XQuery language syntax does not pose any restrictions on the style of recursion that can be described. The common approaches to deal with recursion in relational systems, in contrast, cannot cope with all these variants of recursion. A second problem is that the kind of recursion used in a given query (e.g., tail recursion) used in a given query seems quite tricky to infer (and a consistent treatment of this case in the algebraic compiler adds another challenge). Hence, we decided to go for a limited recursion feature in Pathfinder first. We may later on try to add a more generic handling. We are currently implementing a *syntax extension* to Pathfinder that allows to describe a limited notion of recursion. The new construct with $var seeded by expr1 recurse expr2 will have the following semantics: 1. expr1 is evaluated once and then used as a seed to initiate the recursion. $var is bound to the result of expr1 in the first recursion step. 2. Then, expr2 is evaluated over and over. Variable $var is visible in expr2 and for each recursion step will be bound to the union of all items (nodes) obtained in the previous recursion steps. (The results of all recursion steps are collected into the overall result using set semantics.) 3. Recursion terminates if a recursion step does not contribute any new items (nodes) to the overall result (i.e., we reached a fixpoint). (Remark: There still is some discussion if (for performance reasons) each recursion step should only observe the *new* items obtained in the previous recursion step, or whether the entire result set collected so far should be observable in expr2.) The `union' semantics of this new recursion construct implies that we can do recursion only on *nodes*, not on atomic values. This quite directly matches the requirements of the UVA group (and others) that are looking for a "transitive closure" operator. Note that the above syntax extension that we are about to introduce does not interfere with any existing constructs. So our changes will not affect any (existing) valid XQuery expression. Motivation: There is a high demand for transitive closure functionality in the group at UVA (i.e., Loredana and others), but also in other research groups (as I was told). Transitive closure is, e.g., a vital component of an XPath dialect known as "Regular XPath". Regards from Garching Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Software is like sex: It's better when it's free -- Linus B. Torvalds

1 0

[Monetdb-developers] MT_sleep_ns()?
by Jens Teubner 21 Sep '06

21 Sep '06

Hi all, in shredder.mx there is a call to MT_sleep_ns(). This came with the "new_update" merger. I cannot find, however, any definition of this function. The only thing I can find is MT_sleep_ms() in gdk_posix.mx. Is this a typo? If so, could anybody fix this? This seems to break compilation on Cygwin (at least as reported by our student). Regards Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 This email was written with 100% recycled electrons.

2 1

[Monetdb-developers] PF: back-merging the "new_updates" branch into the HEAD
by Stefan Manegold 20 Sep '06

20 Sep '06

Dear Pathfinder developers, you might have noticed, that Peter checked in the initial "raw" version of his new revised extended XML/XQuery update implementation into a "new_updates" branch of the pathfinder repository last Monday (Sep 11 2006). Since then, we spent a week on consolidating the code with respect to compilation and testing --- at least on our major development platform Fedora Core 4. We had decided to use a branch, first, so that the consolidation phase would not interfere with other development going on on the development trunk (HEAD). With most of the issues solved, we're now down to only 26 out of 1282 tests failing; see http://monetdb.cwi.nl/testing/projects/monetdb/new_updates.35/ for details. We consider this stable "enough" to merge the "new_updates" branch back into the development trunk (HEAD) A.S.A.P., i.e., preferably tomorrow, in order to (1) avoid further double-lane development and the resulting synchronization overhead/problems, (2) put the new code under the surveillance of automatic *multi-platform* testing, and (3) give more of us the opportunity to test the new code both as such and in combination with their own extensions. In particular, the following parts need to be tested (more) intensively - algebra version: the test-web XMark tests work fine, more hasn't been tested, yet - StandOff: known to fail, code requires adaption to comply with (new) update schema - Tijah: not tested at all, mainly because no tests are available in CVS, yet - the new document management features: hardly (if at all) tested, yet, tests need to be added Unless there are any severe objections by 2 pm (CEST) tomorrow (Tue, Sep 19 2006), we will perform the back-merge. Thank you very much for your cooperation. 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 |

1 3

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 4, Issue 7
by Jim Foley 18 Sep '06

18 Sep '06

>------------------------------ > >Message: 2 >Date: Sat, 16 Sep 2006 08:37:24 +0200 >From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> >Subject: Re: [Monetdb-developers] Compiled ok under openSUSE 10.1 (32 bit) but some errors in the tests > >Hi Jim, > >Thanks for your interest in MonetDB/SQL. > >On 15-09-2006 19:09:10 -0400, Jim Foley wrote: >> I freed up a linux server and got MonetDB 4.12.0 and the SQL client to >> compile and run under openSUSE 10.1 with a AMD 3800 64 bit processor. >> It seems to work fine but I am getting some errors on the test for >> both the DB and the SQL client. I understand from the archives that >> some errors are normal. Is there a list of errors on each platform? I >> can just copy off the test results before I compile it with as a 64 >> bit app and compare the results but I would prefer to clean up the >> errors if I can under the 32 bit app before I try it under 64 bits. I >> have a DBA background and I could just be being anal. ;-) >If you want to be sure, post the names of the tests failing. We don't have a list of failing tests. You can also compare >your output to that of our (SuSE) test machines on: >> http://monetdb.cwi.nl/testing/projects/monetdb/Stable/MonetDB/.mTests03/ index.html >and http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests03/inde x.html > >I hope this helps. > >Regards > > > ------------------------------ Fabian, Thank you this is exactly what I was looking for. Jim Foley

1 0