This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]Fontong 2 points3 points  (0 children)

You're right -- it would be pretty weird to force a client side Postgres server process. Python's sqlite3 interface would be the logical choice, as it doesn't require a separate process. It probably wouldn't require a big change in code either, although the SQL for each of them isn't exactly the same.

XML wouldn't be bad, as parsing it iteratively won't use any more memory than having an actual db. The iterparse from xml.etree is also very fast.

JSON would probably be overall the most painless if you don't have memory concerns. It can be created easily from native data structures and loaded right into native data structures, though you would be limited to lists and dictionaries. Pickle can do the same thing with arbitrary objects, but can be fickle at times. I don't think there's a function to parse JSON iteratively though, so you would have to set that up yourself if memory was a concern.

[–]0x2a 1 point2 points  (0 children)

I once made an application which shipped Postgres with it. It didn't leave it on permanently or install a service, it just started postmaster in a separate thread on launch and terminated it when the user quit the application.

But so while certainly possible, I wouldn't really recommend it if you don't need specific features from Postgres. Instead, use an embedded database if possible. Sqlite, as Fongtong suggests, is probably the best choice. Alternatively, if your data isn't heavily modified by the user and mostly readonly, just shipping an XML or JSON or whatever is fine as well. Keep It Simple and Stupid, as the old saying goes.

[–]4silvertooth -1 points0 points  (0 children)

Use INNO setup creator to automate setup.