- developers-list - monetdb.org

[Monetdb-developers] core file on assertion violation?
by Mark Bucciarelli 06 Jul '10

06 Jul '10

Hi, I'm debugging an assertion failure I'm seeing w/ Feb2010: rel_optimizer.c:3039: find_index: Assertion `list_length(exps) == list_length(es)' failed. But I can't find the core file. Shouldn't there be one? Running a small C program that calls abort() as the merovingian user does create a core file. Thanks, m

2 1

Re: [Monetdb-developers] MonetDB: Feb2010 - Various small bugfixes (in pf property infere...
by Stefan Manegold 06 Jul '10

06 Jul '10

Jan, are this checkin to the Feb2010 branch (changeset 1e2808a8e416) and your other checkin to the Jun2010 branch (changeset cc8b3ce4c30a) meant for these branches, only, or should they also be propagated to (merged into) the Jun2010 branch (changeset 1e2808a8e416) and default branch (both changesets). In either case, do you take care of the respective merges (both doing and preventing the propagation require merging the heads) yourself, or do you prefer us to do them? Thanks! Stefan On Tue, Jul 06, 2010 at 03:32:22PM +0200, Jan Rittinger wrote: > Changeset: 1e2808a8e416 for MonetDB > URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=1e2808a8e416 > Modified Files: > pathfinder/compiler/algebra/opt/opt_complex.c > pathfinder/compiler/algebra/prop/prop_dom.c > pathfinder/compiler/sql/lalg2sql.brg > Branch: Feb2010 > Log Message: > > Various small bugfixes (in pf property inference, optimizations & SQL code generation). > > > diffs (63 lines): > > diff -r a7a0e0845e56 -r 1e2808a8e416 pathfinder/compiler/algebra/opt/opt_complex.c > --- a/pathfinder/compiler/algebra/opt/opt_complex.c Tue Jul 06 07:29:54 2010 +0200 > +++ b/pathfinder/compiler/algebra/opt/opt_complex.c Tue Jul 06 15:32:06 2010 +0200 > @@ -2118,20 +2118,21 @@ > for (unsigned int i = 0; i < schema.count; i++) > schema.items[i].name = > PFord_order_col_at (p->sem.sort.sortby, i); > - if (PFprop_ckey (p->prop, schema)) { > - *p = *PFla_rowrank ( > - L(p), > - p->sem.sort.res, > - p->sem.sort.sortby); > - modified = true; > - break; > - } > + if (PFprop_ckey (p->prop, schema)) { > + *p = *PFla_rowrank ( > + L(p), > + p->sem.sort.res, > + p->sem.sort.sortby); > + modified = true; > + break; > + } > } > > /* Replace the rownumber operator by a projection > if only its value distribution (keys) are required > instead of its real values. */ > if (!PFprop_req_value_col (p->prop, p->sem.sort.res) && > + !p->sem.sort.part && > PFord_count (p->sem.sort.sortby) == 1 && > PFprop_key (p->prop, > PFord_order_col_at (p->sem.sort.sortby, 0))) { > diff -r a7a0e0845e56 -r 1e2808a8e416 pathfinder/compiler/algebra/prop/prop_dom.c > --- a/pathfinder/compiler/algebra/prop/prop_dom.c Tue Jul 06 07:29:54 2010 +0200 > +++ b/pathfinder/compiler/algebra/prop/prop_dom.c Tue Jul 06 15:32:06 2010 +0200 > @@ -907,9 +907,11 @@ > L(n)->schema.items[i].name), > dom); > > - add_disjdom (dom, > - PFprop_dom (R(n)->prop, > - L(n)->schema.items[i].name)); > + /* we can only infer the disjointness for a single column */ > + if (n->schema.count == 1) > + add_disjdom (dom, > + PFprop_dom (R(n)->prop, > + L(n)->schema.items[i].name)); > } > break; > > diff -r a7a0e0845e56 -r 1e2808a8e416 pathfinder/compiler/sql/lalg2sql.brg > --- a/pathfinder/compiler/sql/lalg2sql.brg Tue Jul 06 07:29:54 2010 +0200 > +++ b/pathfinder/compiler/sql/lalg2sql.brg Tue Jul 06 15:32:06 2010 +0200 > @@ -4078,7 +4078,7 @@ > } > /* In case the column did not exist in > the column list already ... */ > - if (!found) > + if (!found && !IS_LITERAL(expr)) > /* ... extend the group by list. */ > groupbylist = column_list (groupbylist, expr); > } break; > _______________________________________________ > Checkin-list mailing list > Checkin-list(a)monetdb.org > http://mail.monetdb.org/mailman/listinfo/checkin-list -- | 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-4199 |

1 0

Re: [Monetdb-developers] MonetDB: Jun2010 - undo of changeset 36556:2b71eda5b9e9 "re-appr...
by Stefan Manegold 06 Jul '10

06 Jul '10

On Tue, Jul 06, 2010 at 08:00:58AM +0200, Stefan Manegold wrote: > Changeset: 81cd1d637c34 for MonetDB > URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=81cd1d637c34 > Modified Files: > sql/src/test/leaks/Tests/check0.stable.out > sql/src/test/leaks/Tests/check1.stable.out > sql/src/test/leaks/Tests/check2.stable.out > sql/src/test/leaks/Tests/check3.stable.out > sql/src/test/leaks/Tests/check4.stable.out > sql/src/test/leaks/Tests/check5.stable.out > sql/src/test/leaks/Tests/drop3.stable.out > sql/src/test/leaks/Tests/select1.stable.out > sql/src/test/leaks/Tests/select2.stable.out > sql/src/test/leaks/Tests/temp1.stable.out > sql/src/test/leaks/Tests/temp2.stable.out > sql/src/test/leaks/Tests/temp3.stable.out > Branch: Jun2010 > Log Message: > > undo of changeset 36556:2b71eda5b9e9 "re-approved stable output --- hope this is OK and not a leak ..." > > for a yet unknown reason, tests seem to behave differently with my Jun2010 build > than with nightly testing ans Niels' build ... > The reason turned out to be a compiled & installed geom, which is nowadays of course loaded automatically if available ... Might indeed be more MonetDB5 & sql tests that behave differently depending on whether geom is available or not, and likewise MonetDB5 tests that behave differently depending on whether sql is available or not. Until we make those tests behave identically in either case, nightly testing should be the reference point. With nightly testing, when testing MonetDB5 neither sql nor geom are available, and when testing sql, geom is not available. Hence, these outputs should be approved. Stefan > > diffs (162 lines): > > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check0.stable.out > --- a/sql/src/test/leaks/Tests/check0.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check0.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 161 ] > +[ "transient", 157 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check1.stable.out > --- a/sql/src/test/leaks/Tests/check1.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check1.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 161 ] > +[ "transient", 157 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check2.stable.out > --- a/sql/src/test/leaks/Tests/check2.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check2.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 161 ] > +[ "transient", 157 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check3.stable.out > --- a/sql/src/test/leaks/Tests/check3.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check3.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 181 ] > +[ "transient", 177 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check4.stable.out > --- a/sql/src/test/leaks/Tests/check4.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check4.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 181 ] > +[ "transient", 177 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/check5.stable.out > --- a/sql/src/test/leaks/Tests/check5.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/check5.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -163,7 +163,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 181 ] > +[ "transient", 177 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/drop3.stable.out > --- a/sql/src/test/leaks/Tests/drop3.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/drop3.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -29,7 +29,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 181 ] > +[ "transient", 177 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/select1.stable.out > --- a/sql/src/test/leaks/Tests/select1.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/select1.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -34,7 +34,7 @@ > % L1 # name > % wrd # type > % 3 # length > -[ 122 ] > +[ 118 ] > #select 1; > % . # table_name > % single_value # name > @@ -45,7 +45,7 @@ > % L1 # name > % wrd # type > % 3 # length > -[ 122 ] > +[ 118 ] > > # 22:03:05 > > # 22:03:05 > Done. > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/select2.stable.out > --- a/sql/src/test/leaks/Tests/select2.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/select2.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -34,7 +34,7 @@ > % L1 # name > % wrd # type > % 3 # length > -[ 122 ] > +[ 118 ] > #select 1; > % . # table_name > % single_value # name > @@ -45,7 +45,7 @@ > % L1 # name > % wrd # type > % 3 # length > -[ 122 ] > +[ 118 ] > > # 22:03:05 > > # 22:03:05 > Done. > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/temp1.stable.out > --- a/sql/src/test/leaks/Tests/temp1.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/temp1.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -29,7 +29,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 164 ] > +[ "transient", 160 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/temp2.stable.out > --- a/sql/src/test/leaks/Tests/temp2.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/temp2.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -29,7 +29,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 164 ] > +[ "transient", 160 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > diff -r b1df4a254d3e -r 81cd1d637c34 sql/src/test/leaks/Tests/temp3.stable.out > --- a/sql/src/test/leaks/Tests/temp3.stable.out Tue Jul 06 07:31:15 2010 +0200 > +++ b/sql/src/test/leaks/Tests/temp3.stable.out Tue Jul 06 08:00:52 2010 +0200 > @@ -29,7 +29,7 @@ > % L1, L2 # name > % char, wrd # type > % 9, 3 # length > -[ "transient", 189 ] > +[ "transient", 185 ] > #select 'persistent', count(*) from bbp() as bbp where kind like 'pers%'; > % .L3, .bbp # table_name > % L3, L4 # name > _______________________________________________ > Checkin-list mailing list > Checkin-list(a)monetdb.org > http://mail.monetdb.org/mailman/listinfo/checkin-list > -- | 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-4199 |

1 0

Re: [Monetdb-developers] MonetDB: Jun2010 - added test for fixed bug 2552 PREPARE: limit ...
by Fabian Groffen 02 Jul '10

02 Jul '10

On 02-07-2010 08:48:18 +0200, Niels Nes wrote: > Changeset: 64acf9744dca for MonetDB > URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=64acf9744dca > Modified Files: > clients/src/mapiclient/dump.c ^^^^^ > sql/src/test/BugTracker-2010/Tests/All > sql/src/test/BugTracker-2010/Tests/limit_in_prepare.Bug-2552.sql > sql/src/test/BugTracker-2010/Tests/limit_in_prepare.Bug-2552.stable.err > sql/src/test/BugTracker-2010/Tests/limit_in_prepare.Bug-2552.stable.out > Branch: Jun2010 > Log Message: > > added test for fixed bug 2552 PREPARE: limit statement not recognised > > > diffs (158 lines): > > diff -r 1ee337e08430 -r 64acf9744dca clients/src/mapiclient/dump.c > --- a/clients/src/mapiclient/dump.c Fri Jul 02 08:30:13 2010 +0200 > +++ b/clients/src/mapiclient/dump.c Fri Jul 02 08:47:25 2010 +0200 > @@ -911,7 +911,7 @@ > const char functions[] = "SELECT \"f\".\"func\" " > "FROM \"sys\".\"schemas\" \"s\"," > "\"sys\".\"functions\" \"f\" " > - "WHERE \"f\".\"sql\" = TRUE AND " > + "WHERE \"f\".\"id\" > 2000 AND " Was this an intended commit? (I also have problems with 'hg commit' doing a global commit instead of only the subtree from where you commit ...) > "\"s\".\"id\" = \"f\".\"schema_id\"" > "%s%s%s " > "ORDER BY \"f\".\"id\""; > diff -r 1ee337e08430 -r 64acf9744dca sql/src/test/BugTracker-2010/Tests/All > --- a/sql/src/test/BugTracker-2010/Tests/All Fri Jul 02 08:30:13 2010 +0200 > +++ b/sql/src/test/BugTracker-2010/Tests/All Fri Jul 02 08:47:25 2010 +0200

2 1

[Monetdb-developers] python adapter: transaction semantics and connection.close()
by Mark Bucciarelli 30 Jun '10

30 Jun '10

Hey Gijs, I'm seeing a difference in how MonetDB and SQLite handle transactions inside Django. Here's my current unit test in Django (it passes w/ SQLite and fails with MonetDB): 1 : s1 = Simple(name="mark") 2 : s1.save() 3 : 4 : s2 = Simple(name="mark") 5 : try: 6 : s2.save() 7 : except IntegrityError: 8 : pass 9 : 10 : s = Simple.objects.get(name="mark") 11 : print s What happens under SQLite is the save on line 6 fails, but the select on line 10 works. In MonetDB, at line 10, I get the error current transaction is aborted (please ROLLBACK) Here's the trace of mapi2 commands, starting from line 2 mapi2.py, cmd, operation = sINSERT INTO "testapp_simple" ("name") VALUES ('mark'); mapi2.py, cmd, operation = Xreply_size 1 mapi2.py, cmd, operation = sCOMMIT; mapi2.py, cmd, operation = Xreply_size 1000 mapi2.py, cmd, operation = sINSERT INTO "testapp_simple" ("name") VALUES ('mark'); mapi2.py, cmd, operation = Xreply_size 1000 mapi2.py, cmd, operation = sSELECT "testapp_simple"."id", "testapp_simple"."name" FROM "testapp_simple" WHERE "testapp_simple"."name" = 'mark' ; mapi2.py, cmd, operation = Xreply_size 1 mapi2.py, cmd, operation = sROLLBACK; It looks like the ROLLBACK isn't executed until the connection closes. With auto commit off, shouldn't the ROLLBACK fire as soon as the insert fails? If so, how do I fix this? Thanks m

1 1

[Monetdb-developers] python adapter: registering new Monetizer types?
by Mark Bucciarelli 30 Jun '10

30 Jun '10

Hi, I'm working on the Django adapter again, and have run into a snag. I think the Python MonetDB wrapper may need a new method, but before building a patch I wanted to share the idea and get your feedback. The issue is this: Django uses the field type SafeUnicode. Monetizer doesn't have a mapping for this, and thus raises a ProgrammerError exception. (This is unicode that is safe to disply on an HTML page, and is used for all slug fields, which are common in Django.) The SQLite adapter handles this via a register_adapter method on the Database object. PostgreSQL uses psycopg2.extensions.register_adapter(). MySQL Python adapter exposes a encoders() method on the connection object. It seems the cleanest solution would be to mimic SQLite (if you want this for one connection, you most likely want it for all connections), and be able to do something like this: Database.register_adapter( type(SafeUnicode), lambda s:unicode(s) ) But it wasn't clear to me how to implement this. Somehow that call needs to make it into Montizer mapping dictionary. Thanks, Mark

2 4

[Monetdb-developers] encoding of strings returned by Python client
by Mark Bucciarelli 28 Jun '10

28 Jun '10

Any chance the Python client could be modified to return strings in Unicode instead of UTF-8? Seems like a better fit for Python; for example, that's how Python's sqlite3 module behaves. An alternative approach is to expose a set_encoding method on the connection that let's you specify the encoding of all text fields returned. If backward compatibility is an issue, the latter idea seems better even though it adds a knob. Any comments? (Is the maintainer of the Python adapter active even on this list? I didn't see many Python-specific posts in the archives.) Thanks, m

3 12

Re: [Monetdb-developers] MonetDB: Jun2010 - make it possible to use '?' in offset and limit
by Sjoerd Mullender 23 Jun '10

23 Jun '10

Niels, can you create a Changlog entry, please? On 2010-06-22 15:25, Niels Nes wrote: > Changeset: 600a35cbf6c0 for MonetDB > URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=600a35cbf6c0 > Modified Files: > sql/src/server/bin_optimizer.mx > sql/src/server/rel_bin.mx > sql/src/server/rel_schema.mx > sql/src/server/rel_select.mx > sql/src/server/sql_parser.mx > sql/src/server/sql_statement.mx > sql/src/server/sql_symbol.mx > sql/src/test/BugTracker-2009/Tests/POWER_vs_prod.SF-2596114.stable.out > sql/src/test/Dependencies/Tests/Dependencies.stable.out > Branch: Jun2010 > Log Message: > > make it possible to use '?' in offset and limit > (transplanted from 61c37c0d76f8ee3359bda98cc25e750b5201ae56) > > > diffs (truncated from 482 to 300 lines): > > diff -r d83c56c4bba7 -r 600a35cbf6c0 sql/src/server/bin_optimizer.mx > --- a/sql/src/server/bin_optimizer.mx Tue Jun 22 14:39:09 2010 +0200 > +++ b/sql/src/server/bin_optimizer.mx Mon Jun 21 23:35:09 2010 +0200 > @@ -288,9 +288,9 @@ > stmt *r = stmt_dup(j->op2.stval); > > l = stmt_limit(l, > - s->op2.stval->op1.aval->data.val.wval, > - s->op3.stval->op1.aval->data.val.wval, > - s->flag); > + stmt_dup(s->op2.stval), > + stmt_dup(s->op3.stval), > + s->flag); > s = stmt_join(l, r, cmp_equal); > ns = bin_optimizer(c, s); > stmt_destroy(s); > @@ -311,9 +311,9 @@ > stmt *r = stmt_dup(j->op2.stval); > > r = stmt_limit(r, > - s->op2.stval->op1.aval->data.val.wval, > - s->op3.stval->op1.aval->data.val.wval, > - s->flag); > + stmt_dup(s->op2.stval), > + stmt_dup(s->op3.stval), > + s->flag); > s = stmt_join(l, r, cmp_equal); > ns = bin_optimizer(c, s); > stmt_destroy(s); > @@ -325,8 +325,8 @@ > /* try to push the limit through the order */ > if (j->type == st_order) { > s = stmt_order(stmt_limit(stmt_dup(j->op1.stval), > - s->op2.stval->op1.aval->data.val.wval, > - s->op3.stval->op1.aval->data.val.wval, > + stmt_dup(s->op2.stval), > + stmt_dup(s->op3.stval), > LIMIT_DIRECTION(j->flag,1,0)), j->flag); > ns = bin_optimizer(c, s); > stmt_destroy(s); > @@ -338,8 +338,8 @@ > /* try to push the limit through the reverse */ > if (!s->flag && j->type == st_reverse) { > s = stmt_reverse(stmt_limit(stmt_dup(j->op1.stval), > - s->op2.stval->op1.aval->data.val.wval, > - s->op3.stval->op1.aval->data.val.wval, > + stmt_dup(s->op2.stval), > + stmt_dup(s->op3.stval), > 0)); > ns = bin_optimizer(c, s); > stmt_destroy(s); > @@ -351,8 +351,9 @@ > /* try to push the limit through the mark (only if there is no offset) */ > if (!s->op2.stval->op1.aval->data.val.wval && j->type == st_mark) { > s = stmt_mark_tail(stmt_limit(stmt_dup(j->op1.stval), > - s->op2.stval->op1.aval->data.val.wval, > - s->op3.stval->op1.aval->data.val.wval, s->flag), > + stmt_dup(s->op2.stval), > + stmt_dup(s->op3.stval), > + s->flag), > j->op2.stval->op1.aval->data.val.ival); > ns = bin_optimizer(c, s); > stmt_destroy(s); > diff -r d83c56c4bba7 -r 600a35cbf6c0 sql/src/server/rel_bin.mx > --- a/sql/src/server/rel_bin.mx Tue Jun 22 14:39:09 2010 +0200 > +++ b/sql/src/server/rel_bin.mx Mon Jun 21 23:35:09 2010 +0200 > @@ -1478,32 +1478,26 @@ > return stmt_list(l); > } > > -static wrd > +static sql_exp* > topn_limit( sql_rel *rel ) > { > if (rel->exps) { > sql_exp *limit = rel->exps->h->data; > - atom *a = limit->l; > - > - return a->data.val.wval; > + > + return limit; > } > - return -1; > + return NULL; > } > > -static wrd > +static sql_exp* > topn_offset( sql_rel *rel ) > { > - wrd o = 0; > - > if (rel->exps && list_length(rel->exps) > 1) { > sql_exp *offset = rel->exps->h->next->data; > - atom *a = offset->l; > - > - o = a->data.val.wval; > - if (o <= 0) > - o = 0; > + > + return offset; > } > - return o; > + return NULL; > } > > static sql_table * > @@ -1524,15 +1518,24 @@ > list *pl; > node *en, *n; > stmt *sub = NULL, *psub = NULL; > - wrd l = -1; > + stmt *l = NULL; > > if (topn) { > - wrd o = topn_offset(topn); > - l = topn_limit(topn); > - if (l < 0) /* for now only handle topn > + sql_exp *le = topn_limit(topn); > + sql_exp *oe = topn_offset(topn); > + > + if (!le) { /* for now only handle topn > including limit, ie not just offset */ > topn = NULL; > - l += o; > + } else { > + l = exp_bin(sql, le, NULL, NULL, NULL, NULL); > + if (oe) { > + sql_subtype *wrd = sql_bind_localtype("wrd"); > + sql_subfunc *add = sql_bind_func_result(sql->session->schema, "sql_add", wrd, wrd, wrd); > + stmt *o = exp_bin(sql, oe, NULL, NULL, NULL, NULL); > + l = stmt_binop(l, o, add); > + } > + } > } > > if (!rel->exps) > @@ -1591,7 +1594,7 @@ > stmt_destroy(sub); > return NULL; > } > - limit = stmt_limit(orderbycols, 0, l, LIMIT_DIRECTION(is_ascending(orderbycole), 1, before_project)); > + limit = stmt_limit(orderbycols, stmt_atom_wrd(0), l, LIMIT_DIRECTION(is_ascending(orderbycole), 1, before_project)); > for ( n=pl->h ; n; n = n->next) { > list_append(npl, > stmt_semijoin(column(stmt_dup(n->data)), > @@ -1902,8 +1905,8 @@ > rel2bin_topn( mvc *sql, sql_rel *rel, list *refs) > { > list *newl; > - wrd l = -1, o = 0; > - stmt *sub = NULL, *order = NULL; > + sql_exp *oe = NULL, *le = NULL; > + stmt *sub = NULL, *order = NULL, *l = NULL, *o = NULL; > node *n; > > if (rel->l) { /* first construct the sub relation */ > @@ -1918,8 +1921,8 @@ > if (!sub) > return NULL; > > - l = topn_limit(rel); > - o = topn_offset(rel); > + le = topn_limit(rel); > + oe = topn_offset(rel); > > if (sub->type == st_ordered) { > stmt *s = stmt_dup(sub->op2.stval); > @@ -1932,18 +1935,25 @@ > > if (n) { > stmt *limit = NULL, *p, *j; > - wrd lmt = l; > - > - if (l < 0) { > + sql_exp *lmt = le; > + > + if (le) > + l = exp_bin(sql, le, NULL, NULL, NULL, NULL); > + if (oe) > + o = exp_bin(sql, oe, NULL, NULL, NULL, NULL); > + > + if (!le) { > l = o; > - o = 0; > + o = stmt_atom_wrd(0); > } > + if (!o) > + o = stmt_atom_wrd(0); > > if (order) { > limit = stmt_limit(stmt_dup(order), o, l, 0); > } else { > limit = stmt_limit(column(stmt_dup(n->data)), o, l, 0); > - if (lmt >= 0) { > + if (lmt) { > n = n->next; > list_append(newl, limit); > } > @@ -1953,7 +1963,7 @@ > j = find_projection_join(limit); > if (j && 0) { > p = find_pivot(j); > - if (lmt < 0) > + if (!lmt) > p = stmt_diff(stmt_dup(p), stmt_dup(limit)); > else > p = stmt_semijoin(stmt_dup(p), stmt_dup(limit)); > @@ -1971,7 +1981,7 @@ > for ( ; n; n = n->next) { > stmt *s; > > - if (lmt < 0) > + if (!lmt) > s = stmt_diff(column(stmt_dup(n->data)), stmt_dup(limit)); > else > s = stmt_semijoin(column(stmt_dup(n->data)), stmt_dup(limit)); > @@ -1979,7 +1989,7 @@ > } > } > if (order) { > - if (lmt < 0) { > + if (!lmt) { > order = stmt_diff(order, limit); > } else { > stmt_destroy(order); > diff -r d83c56c4bba7 -r 600a35cbf6c0 sql/src/server/rel_schema.mx > --- a/sql/src/server/rel_schema.mx Tue Jun 22 14:39:09 2010 +0200 > +++ b/sql/src/server/rel_schema.mx Mon Jun 21 23:35:09 2010 +0200 > @@ -859,7 +859,7 @@ > if (query->token == SQL_SELECT) { > SelectNode *sn = (SelectNode *) query; > > - if (sn->limit >= 0) > + if (sn->limit) > return sql_error(sql, 01, "CREATE VIEW: LIMIT not supported"); > if (sn->orderby) > return sql_error(sql, 01, "CREATE VIEW: ORDER BY not supported"); > diff -r d83c56c4bba7 -r 600a35cbf6c0 sql/src/server/rel_select.mx > --- a/sql/src/server/rel_select.mx Tue Jun 22 14:39:09 2010 +0200 > +++ b/sql/src/server/rel_select.mx Mon Jun 21 23:35:09 2010 +0200 > @@ -4644,12 +4644,31 @@ > if (!rel) > return NULL; > > - if (sn->limit > 0 || sn->offset > 0) { > + if (sn->limit || sn->offset) { > + sql_subtype *wrd = sql_bind_localtype("wrd"); > list *exps = new_exp_list(); > > - append(exps, exp_atom_wrd(sn->limit)); > - if (sn->offset > 0) > - append(exps, exp_atom_wrd(sn->offset)); > + if (sn->limit) { > + sql_exp *l = rel_value_exp( sql, NULL, sn->limit, 0, ek); > + > + if (!l || !(l=rel_check_type(sql, wrd, l, type_equal))) > + return NULL; > + if ((ek.card != card_relation && sn->limit) && > + (ek.card == card_value && sn->limit)) { > + sql_subaggr *zero_or_one = sql_bind_aggr(sql->session->schema, "zero_or_one", exp_subtype(l)); > + > + l = exp_aggr1(l, zero_or_one, 0, 0, CARD_ATOM, 0); > + } > + // return sql_error(sql, 01, "SELECT: LIMIT only allowed on outermost SELECT"); > + append(exps, l); > + } else > + append(exps, NULL); > + if (sn->offset) { > + sql_exp *o = rel_value_exp( sql, NULL, sn->offset, 0, ek); > + if (!o || !(o=rel_check_type(sql, wrd, o, type_equal))) > + return NULL; > + append(exps, o); > + } > rel = rel_topn(rel, exps); > } > return rel; > @@ -4670,10 +4689,6 @@ > return table_ref(sql, rel, sq); > assert(sn->s.token == SQL_SELECT); > > - if ((ek.card != card_relation && sn->limit >= 0) && > - (ek.card == card_value && sn->limit != 1)) > - return sql_error(sql, 01, "SELECT: LIMIT only allowed on outermost SELECT"); > - > if (ek.card != card_relation && sn->orderby) > return sql_error(sql, 01, "SELECT: ORDER BY only allowed on outermost SELECT"); > > diff -r d83c56c4bba7 -r 600a35cbf6c0 sql/src/server/sql_parser.mx > --- a/sql/src/server/sql_parser.mx Tue Jun 22 14:39:09 2010 +0200 > +++ b/sql/src/server/sql_parser.mx Mon Jun 21 23:35:09 2010 +0200 > @@ -388,6 +388,9 @@ > ordering_spec > simple_table > table_ref > + opt_limit > + opt_offset > + param > case_exp > case_scalar_exp > _______________________________________________ > Checkin-list mailing list > Checkin-list(a)monetdb.org > http://mail.monetdb.org/mailman/listinfo/checkin-list -- Sjoerd Mullender

1 0

[Monetdb-developers] specifying NULL when using ODBC param_query
by kss ram 20 Jun '10

20 Jun '10

Hello Everyone, Is there any way to specify a null value when using ODBC param_query, in case of SQL_Query we do not really end up facing this problem as we build our own query string and then execute sql_query, sql_query is potentially unsafe of sql injection attacks, and thus using param_query makes alot of sense, but param query makes it hard to specify the data type nuetral NULL value, if we try specifying blank values like 0 in case of number and "" in case of string, these blank values will end up taking space in the database and thus would be expensive in terms of memory consumption, a database specific NULL value would leave the field null with no memory consumption. Thank you everyone in advance. kss ram

2 1

Re: [Monetdb-developers] MonetDB: default - MAP_ANONYMOUS instead of MAP_ANON
by Stefan Manegold 17 Jun '10

17 Jun '10

Niels, is this just precaution --- `man mmap` says " MAP_ANON Synonym for MAP_ANONYMOUS. Deprecated. " --- or bug fix that should be back-ported to the Jun2010 branch (I could do that)? Thanks. Stefan On Thu, Jun 17, 2010 at 09:47:40PM +0200, Niels Nes wrote: > Changeset: 57878a477b7c for MonetDB > URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=57878a477b7c > Modified Files: > MonetDB/src/gdk/gdk_posix.mx > Branch: default > Log Message: > > MAP_ANONYMOUS instead of MAP_ANON > > > diffs (14 lines): > > diff -r 99d16aff6ce6 -r 57878a477b7c MonetDB/src/gdk/gdk_posix.mx > --- a/MonetDB/src/gdk/gdk_posix.mx Thu Jun 17 14:39:08 2010 +0200 > +++ b/MonetDB/src/gdk/gdk_posix.mx Thu Jun 17 21:47:00 2010 +0200 > @@ -2105,8 +2105,8 @@ > > #define MT_PAGESIZE(s) ((((s)-1)/MT_pagesize()+1)*MT_pagesize()) > > -#if defined(MAP_ANON) > -#define MMAP_FLAGS(f) f|MAP_ANON > +#if defined(MAP_ANONYMOUS) > +#define MMAP_FLAGS(f) f|MAP_ANONYMOUS > #define MMAP_FD -1 > #define MMAP_OPEN_DEV_ZERO int fd = 1 > #define MMAP_CLOSE_DEV_ZERO (void)fd > _______________________________________________ > Checkin-list mailing list > Checkin-list(a)monetdb.org > http://mail.monetdb.org/mailman/listinfo/checkin-list -- | 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-4199 |

1 0