Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id A2DEC9FA372 for ; Sat, 16 Dec 2006 07:48:11 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 03784-06 for ; Sat, 16 Dec 2006 07:47:55 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 0AC129FA364 for ; Sat, 16 Dec 2006 07:47:59 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from swarthymail-a3.dreamhost.com (sd-green-bigip-119.dreamhost.com [208.97.132.119]) by svr4.postgresql.org (Postfix) with ESMTP id 33C145AF031 for ; Sat, 16 Dec 2006 11:47:58 +0000 (GMT) Received: from [192.168.2.44] (u25-56.dsl.vianetworks.de [212.168.164.56]) by swarthymail-a3.dreamhost.com (Postfix) with ESMTP id 0D1CC7F01B; Sat, 16 Dec 2006 03:47:55 -0800 (PST) Subject: Re: Embedding postgresql in my application From: Murray Cumming To: "Jeroen T. Vermeulen" Cc: pgsql-interfaces In-Reply-To: <9856.125.24.243.222.1166268615.squirrel@webmail.xs4all.nl> References: <1166225144.12609.2.camel@localhost.localdomain> <20058.125.24.243.222.1166249768.squirrel@webmail.xs4all.nl> <1166267606.5923.11.camel@localhost.localdomain> <9856.125.24.243.222.1166268615.squirrel@webmail.xs4all.nl> Content-Type: text/plain Date: Sat, 16 Dec 2006 12:47:53 +0100 Message-Id: <1166269673.5923.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.026 tagged_above=0 required=5 tests=AWL, BAYES_50 X-Spam-Level: X-Archive-Number: 200612/14 X-Sequence-Number: 6348 On Sat, 2006-12-16 at 18:30 +0700, Jeroen T. Vermeulen wrote: > There is no issue of ports, really. The way I've described it, you do > *not* need a TCP port. Every instance of postgres is running on its own > socket, which appears in the filesystem in a place of your choosing. Well, I want multiple users, from multiple networked computers to be able to use the database simultaneously. TCP/IP seems the logical way to do this. > > In this case, I'd actually like the location of the database data to be > > different every time. The idea would be that it would all be contained > > in a directory (or even a tarball archive, but that's another issue), > > along with the .glom file. And opening the .glom file would start a > > postgres instance with the database that's in that directory. > > That should work fine, but yes, then you do need a separate postgres > instance running for each of those directories. > > > > In my each-database-in-its-directory idea, I guess that I'd do both an > > initdb (to create the cluster) and a createdb (to create the database, > > in the cluster, after a createuser) once. > > Yes. Except for the createuser: if user X owns these directories and > postgres is started under user identity X, then X is automatically (well, > by default) the superuser for that database. No need to create it. Are we talking about a Linux user or Postgres user as "user X"? I thought they were separate lists of users. > > Or do initdb and createdb change anything outside of the specified > > directory? I mean, can I really move that directory around and just > > start a postgres instance on it after it's moved, without changes. Are > > there any absolute filepaths I should watch out for, for instance? > > There's the configuration files, of course, in /etc/postgresql*. You'll > have to look up the necessary options to replace those with local > versions. Is there no way to put the configuration file in the directory too? > > Actually, I want passwords. This is not just for the internal use of the > > application. I want Glom systems to be usable by multiple users > > simultaneously. That's a big reason why I'm not using sqllite for this. > > That doesn't mean that you have to have passwords, though. With "ident > sameuser" you simply rely on the system's authentication--if the system > says you're user X, then the database accepts you as X, but if the system > says you're not X, then the database will not accept you as X either. > Overall that's probably safer, not less safe, than requiring the user to > enter a password to log into the database. And it's lots safer than > keeping a password stored in a file somewhere. I don't want to require all users to be using the same Linux user system, and I even want to allow Windows users to connect when I port Glom to Windows. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com