From dev-return-17178-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Sep 07 02:37:14 2006 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 81650 invoked from network); 7 Sep 2006 02:37:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Sep 2006 02:37:02 -0000 Received: (qmail 64352 invoked by uid 500); 7 Sep 2006 02:37:02 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 63993 invoked by uid 500); 7 Sep 2006 02:37:01 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 63980 invoked by uid 99); 7 Sep 2006 02:37:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Sep 2006 19:37:01 -0700 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [209.191.85.35] (HELO web36701.mail.mud.yahoo.com) (209.191.85.35) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 06 Sep 2006 19:36:50 -0700 Received: (qmail 83108 invoked by uid 60001); 7 Sep 2006 02:36:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O+nDRWeALF0rOwnIWz+LcvkIhIyBc9PdYKGO/Fl0CqTvX5cevVCMaJdKJS4YUNxS8vEGSaAaA3vN3K3yLic3XtuDO/yni8O80vj4LFmc0ususnVIxqwLt6tvYwWOsh9yBl1C82X1xzC7Pix80mpV+gJThhoiGIxFs7/cG32bP+k= ; Message-ID: <20060907023623.83106.qmail@web36701.mail.mud.yahoo.com> Received: from [203.173.41.22] by web36701.mail.mud.yahoo.com via HTTP; Wed, 06 Sep 2006 19:36:23 PDT Date: Wed, 6 Sep 2006 19:36:23 -0700 (PDT) From: Alex Dubov Subject: Re: DBD: Prepared statements, BLOBs etc. To: dev@apr.apache.org In-Reply-To: <20060907091627.keukvlkfk0ogc8gw@www.rexursive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I was not following the topic lately, so excuse me if I'm out of sync. > Which brings me to my reasoning why apr_dbd_blob_t doesn't contain a > brigade (one of the proposals that was floating on the list), but > rather a flat data pointer and size (in case you were wondering). The > caller is in a much better position to control memory allocation > issues here and leaving the "flattening" of a brigade to DBD functions > can bring about all kinds of unwanted memory allocation effects. In > the end, most databases deal with a flat chunk of memory and that's > what callers mostly have anyway. It also was my idea on going this way some time ago, but now I see the light. I actually believe that there is a considerable advantage in using buckets (not brigades) when passing binary data to and from the database. And heap buckets behave in a way user will expect from *_blob_t or any similar structure. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com