Yes, that's how I work too. My home server contains a Postgres instance that I use for pretty much everything. It's quite convenient.
Regards, Elias On 10 July 2014 12:53, Blake McBride <blake1...@gmail.com> wrote: > Greetings, > > PostgreSQL is very important to, at least, me. I do a lot of production > work in PostgreSQL. I like SQLite too, but I would only use it when the > data didn't relate to anything but APL. Here is what I propose. Since > your component file system rides on top of SQL, and the standard doesn't > know or care about anything below the APL level, we should add a function > that allows the user to specify the database information (dbname, user, > password, etc.). That call would be made as sort of a setup step. Once > that setup step is specified, all of the standard API should work as > described. > > This will give us a totally standard API. If someone wants to switch to > GNU APL, all they have to do is add one function to specify the database. > Not too much to ask. > > We kind of have to do this. Even with SQLite, you still have to specify > the database name (I presume one database contains many component files). > > Thanks. > > Blake > > > > On Wed, Jul 9, 2014 at 9:44 PM, David B. Lamkins <dlamk...@gmail.com> > wrote: > >> I'm certainly willing to consider alternatives. IIUC, lib_sql also >> supports PostgreSQL. Anything else? >> >> How do I tell lib_sql to use a PostgreSQL server? >> >> The argument in favor of SQLite, of course, is that it's serverless. No >> additional setup (beyond the installation of the library) required. >> >> Would there be any additional benefits or concerns when connecting to a >> PostgreSQL server? >> >> As you've no doubt noticed, there's nothing in the code (or in the >> standard API) to acknowledge or support the notion of multiple users. >> Again: point in favor of SQLite... >> >> >> On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote: >> > I was looking at your code, and I noticed that it's SQLite-specific. >> > WOuldn't it make sense to make it SQL-implementation-agnostic? >> > >> > >> > Based on what I can see, the only SQLite-specific SQL you have in >> > there is "replace into" which I had never heard about before. >> > >> > >> > Regards, >> > Elias >> > >> > >> > On 9 July 2014 01:22, David Lamkins <da...@lamkins.net> wrote: >> > I haven't yet written test scripts, but I've informally tested >> > all of the functions and am reasonably confident that the >> > component file API is complete and correct. >> > >> > >> > If you'd like to try out the API while I'm working on scripted >> > test cases, the repo is: >> > >> > https://github.com/TieDyedDevil/iso-apl-cf >> > >> > >> > You'll find documentation is in the comments and in Annex A of >> > the ISO 13751 standard. >> > >> > >> > The standard "specifies a minimal set of functions which a >> > conforming implementation must provide"; I've implemented all >> > of these. I've also added several useful functions not >> > mentioned in the standard, including component inquiry, >> > component drop, and transaction support. >> > >> > >> > >> > Note that the code is not packaged for my package manager; I >> > assume that the component file implementation would become an >> > L3 library in the event it's adopted for inclusion in GNU APL. >> > >> > >> > Júergen, I've specified the GPLv3 license since that's what >> > GNU APL uses. If there's a more appropriate choice of license >> > for this library, please let me know. >> > >> > -- >> > "The secret to creativity is knowing how to hide your >> > sources." >> > Albert Einstein >> > >> > >> > http://soundcloud.com/davidlamkins >> > http://reverbnation.com/lamkins >> > http://reverbnation.com/lcw >> > http://lamkins-guitar.com/ >> > http://lamkins.net/ >> > http://successful-lisp.com/ >> > >> > >> >> >> >> >
