Date: 26 Jun 2008 08:03:15 -0000 From: Lapo Luchini <lapo@lapo.it> To: FreeBSD-gnats-submit@FreeBSD.org Cc: mnag@FreeBSD.org, Lapo Luchini <lapo@lapo.it> Subject: ports/125004: databases/sqlite3 with column metadata Message-ID: <20080626080315.24047.qmail@mail.lapo.it> Resent-Message-ID: <200806260810.m5Q8A2uo016140@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 125004 >Category: ports >Synopsis: databases/sqlite3 with column metadata >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Jun 26 08:10:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Lapo Luchini >Release: FreeBSD 6.3-PRERELEASE amd64 >Organization: >Environment: System: FreeBSD motoko.lapo.it 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #8: Thu Dec 13 09:33:49 CET 2007 root@motoko.lapo.it:/usr/obj/usr/src/sys/MOTOKO amd64 >Description: SQLite3 has a compile option to store some (more) metadata in every query result. Normally the "sqlite3_stmt" (the structure that contains a single statement) contains 2*N columns per row: the column name and the column value. With this option the row gets 5*N columns, the extras being database name, table name and origin name. Refer to <http://www.sqlite.org/c3ref/column_database_name.html>; for a longer description. My proposal is to use that option by default. Pros: - some language bindings (e.g. the Sqlite JDBC port I prepared yesterday) need that to implement some of the necessary features of the language (JDBC's ResultSetMetadata.getTableName(int) in Java's case) - very little overhead: 3*N more names in RAM (only once per query, as only one row is fetched at any time), so assuming a database with "normal" names under 20 bytes some 60 bytes per column (I guess something that can run FreeBSD, even if a small embedded, don't bother about that little RAM) - some more ports (probably) could use libsqlite3.so instead of compiling a local version themselves Cons: - unnecessary to most users except when analyzing the result of an unknown query or when implementing a database abstraction interface - libsqlite3.so increases in size by 1460 bytes Another option could be to have that as a (default on) OPTION, but given the very low overhead, I'd simply go for it personally. >How-To-Repeat: >Fix: diff -ruN sqlite3.orig/Makefile sqlite3/Makefile --- sqlite3.orig/Makefile 2008-06-25 10:45:43.000000000 +0200 +++ sqlite3/Makefile 2008-06-26 09:50:27.000000000 +0200 @@ -7,6 +7,7 @@ PORTNAME= sqlite3 PORTVERSION= 3.5.6 +PORTREVISION= 1 CATEGORIES= databases MASTER_SITES= http://www.sqlite.org/ DISTNAME= sqlite-${PORTVERSION} @@ -33,6 +34,8 @@ .include <bsd.port.pre.mk> +CFLAGS+= -DSQLITE_ENABLE_COLUMN_METADATA=1 + .if defined(WITH_DEBUG) CONFIGURE_ARGS+= --enable-debug .endif >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080626080315.24047.qmail>