Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2DC7B2E007C for ; Thu, 6 Mar 2008 02:56:09 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 13099-05 for ; Thu, 6 Mar 2008 02:56:06 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from flame.co.za (ns.flame.co.za [160.124.170.1]) by postgresql.org (Postfix) with ESMTP id 057FB2E004E for ; Thu, 6 Mar 2008 02:56:05 -0400 (AST) Received: from [192.168.0.138] (unknown [196.209.62.7]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTP id 697C9802A0 for ; Thu, 6 Mar 2008 08:54:56 +0200 (SAST) Subject: Re: FAQ on Embedding Postgres From: Theo Kramer Reply-To: theo@flame.co.za To: pgsql-docs@postgresql.org In-Reply-To: <11585.1204784735@sss.pgh.pa.us> References: <200803051502.m25F2fm03349@momjian.us> <718.1204738553@sss.pgh.pa.us> <20080305174126.GM19860@fetter.org> <1029.1204739761@sss.pgh.pa.us> <20080305182500.GN19860@fetter.org> <20080305103043.233761e8@jd-laptop> <20080305105307.2bcce254@jd-laptop> <20080305191717.GV4755@alvh.no-ip.org> <11585.1204784735@sss.pgh.pa.us> Content-Type: text/plain Organization: Flame Computing Enterprises cc Date: Thu, 06 Mar 2008 08:54:23 +0200 Message-Id: <1204786463.2332.11.camel@localhost6.localdomain6> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/29 X-Sequence-Number: 4841 On Thu, 2008-03-06 at 01:25 -0500, Tom Lane wrote: > Greg Smith writes: > > I think it's funny to consider a specific recommendation for SQLite as > > being out of line when you look at the history here. The whole reason > > that software even exists is because of the difficulty of using PostgreSQL > > in this context. See http://www.linuxjournal.com/article/6650 > > I've got nothing against SQLite. But I am unhappy with the idea of us > recommending *any* particular bit of software that is not under our > control, especially in a document that is as widespread and hard to > update as our FAQ. There are any number of scenarios where we might > want to take back such an endorsement, but once made it'll be out there > somewhere on the Web until cockroaches rule the earth. There is also > the whole class of arguments about "why'd you recommend X and not Y?" > that we'd surely get sucked into. Better not to go there in the first > place. From a users point of view - both PostgreSQL and other embedable databases aka file handlers I have to agree - suggesting an alternate product might belong in a book but not in a FAQ which is relevant to PostgreSQL and an integral part of the PostgreSQL documentation. -- Regards Theo