On Wed, 2008-04-16 at 07:19 +0900, Chad P. wrote:
if there might be any other concerns that would make you hesitant to make
this kind of statement, of course.
Thank you for the specific update. I had to edit it somewhat, because
the real limit seems to be actually lower than 255 (and lower than 238).
Regards,
Jeff D.
2008/4/16, Christopher D. [email protected]:
| possible with Ruby as well?
Because Ruby doesn’t really compare to Java in terms of infrastructure
and APIs?While this may be true in some general sense, I don’t think its really all that
relevant here. PostgreSQL’s protocol is documented and supported over
TCP/IP, and Ruby certainly has TCP/IP support, so there is no reason you
couldn’t write a pure Ruby PostgreSQL driver.
Yes, and to prove you right, someone has already done it.
There’s the postgres-pr gem on RubyForge:
http://rubyforge.org/projects/ruby-dbi/
We use it for a Rails app and it works fine on MRI and JRuby.
Although I can’t say how it compares performance wise,
this app has only a couple of users.
On Thu, Apr 17, 2008 at 07:31:33AM +0900, Jeff D. wrote:
for the Ruby community at large in such strong terms, too. I don’t know
if there might be any other concerns that would make you hesitant to make
this kind of statement, of course.Thank you for the specific update. I had to edit it somewhat, because
the real limit seems to be actually lower than 255 (and lower than 238).
I’m glad I could help – and ouch at that character limit.
I like the new text. Thanks for making that clearer.
On Apr 16, 5:43 pm, Jeff D. [email protected] wrote:
On Thu, 2008-04-17 at 03:15 +0900, Luis L. wrote:
Also, I’ll build it against 8.2 since 8.3 as not been promoted to
stable.Promoted to stable by whom? PostgreSQL 8.3.1 is the latest stable
release on all platforms.
By me? 
I got several issues from 5.0 to 5.1 when was dealing with MySQL,
also, there is a bigger 8.2 userbase than 8.3 and we need to verify
API incompatibilities that those shared libraries (DLL) exposes and
make everything crash.
Will be helpful if you can also provide me a mailing list where the
integration builder will output the building results…Something like this:
http://rubyforge.org/pipermail/rubyinstaller-devel/2008-April/000263…
Or this:
http://rubyforge.org/pipermail/rubyinstaller-devel/2008-April/000283…I set up the mailing list ruby-pg-devel.
Great, will make the bot subcribe in it and start dumping build
reports 
Regards,
Having started this huge thread on PostgresSQL, I found…
…after much swearing at the complexities of setting up users and
passwords and permissions in PostgresSQL… (I don’t care, there will
only ever be one user, why am I battling this stuff?! Bugger this for
a bowl of cherries!)
…and now am yet another happy SQLite user.
Soo so so much simpler.
John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand
I can see Jeff’s point. If both libpq and the Postgres JDBC drivers
exist what is the value add and writing a third version that
duplicates their functionality? Certainly it could be a good research
project to see how complexity, bug count, and performance vary across
three implementations but not a great use of Jeff’s time.
Does anyone know which of the Postgres JDBC driver or libpq is most
widely used today and most reliable?
Peter
On Thu, May 22, 2008 at 10:40 PM, John C. [email protected]
wrote:
Having started this huge thread on PostgresSQL, I found…
…after much swearing at the complexities of setting up users and
passwords and permissions in PostgresSQL… (I don’t care, there will
only ever be one user, why am I battling this stuff?! Bugger this for
a bowl of cherries!)…and now am yet another happy SQLite user.
Soo so so much simpler.
If the shoe fits. I would use SQLite more if it had proper relational
algebra under its hood.
Todd
John C. wrote:
Having started this huge thread on PostgresSQL, I found…
…after much swearing at the complexities of setting up users and
passwords and permissions in PostgresSQL… (I don’t care, there will
only ever be one user, why am I battling this stuff?! Bugger this for
a bowl of cherries!)…and now am yet another happy SQLite user.
Soo so so much simpler.
John,
I quite like SQLite actually… though I’m tempted to go to Postgre
mostly for GIS functionality…
Cheers,
Mohit.
5/24/2008 | 12:28 AM.
Todd B. wrote:
Soo so so much simpler.
If the shoe fits. I would use SQLite more if it had proper relational
algebra under its hood.
Would you mind explaining what you mean my that?
John C. [email protected] writes:
…after much swearing at the complexities of setting up users and
passwords and permissions in PostgresSQL… (I don’t care, there will
only ever be one user, why am I battling this stuff?! Bugger this for
a bowl of cherries!)
Don’t ever use MySQL then, freaking permission system from hell.
SQLite is very nice, but I’m quite fond of PostgreSQL. I’ve also been
using it daily for over 8 years, so …
On Fri, 2008-05-23 at 12:40 +0900, John C. wrote:
Having started this huge thread on PostgresSQL, I found…
…after much swearing at the complexities of setting up users and
passwords and permissions in PostgresSQL… (I don’t care, there will
only ever be one user, why am I battling this stuff?! Bugger this for
a bowl of cherries!)…and now am yet another happy SQLite user.
Soo so so much simpler.
I’m glad it worked out. If you have some time, would you mind doing a
quick writeup of what you tried, what you expected, and what you got, so
that if there is unneeded complexity we can fix it for other users?
Generally PostgreSQL installs with fairly liberal permissions for local
access, so the single-user case is usually easy.
It would also be interesting to know what you think of the embedded
version of FirebirdSQL.
I’m not trying to direct you away from SQLite, but it would be helpful
to know at what point you were stuck.
Regards,
Jeff D.
Regards,
Jeff D.
On Fri, 2008-05-23 at 12:24 +0900, Peter B. wrote:
Does anyone know which of the Postgres JDBC driver or libpq is most
widely used today and most reliable?
Libpq is widely used. I’m not sure what exactly you mean by reliable,
but libpq is solid code.
I don’t have any experience with the JDBC driver.
Regards,
Jeff D.
On Sun, May 25, 2008 at 8:29 AM, Will P. [email protected]
wrote:
Soo so so much simpler.
If the shoe fits. I would use SQLite more if it had proper relational
algebra under its hood.Would you mind explaining what you mean my that?
No solid constraints for data integrity. Like foreign key
constraints, for example. Somebody mentioned on this list in a
different thread, though, that this will change in the future. Here’s
a contrived example without caps…
sqlite3 --version
=> 3.4.0
sqlite3
create table food (
ingredient varchar not null primary key
);
create table measurements (
measurement varchar not null primary key
);
create table preparation (
measurement not null references measurements (measurement),
ingredient not null references food (ingredient),
primary key (measurement, ingredient)
);
insert into food values (“garlic”);
insert into measurements (“clove”);
insert into preparation (measurement, ingredient) values (“garlic”,
“clove”);
insert into preparation (measurement, ingredient) values (“clove”,
“garlic”);
select * from preparation;
=> garlic |clove (yes, the result has that space after garlic)
=> clove|garlic
Sort of a bandaid on logic, especially considering that the above code
complies with the SQL92 standard. Hey, but it’s small, fast, and
works for some things.
Sorry for the bad vibe, but people need to be aware that they are not
working with an RDBMS.
Todd
On Sun, May 25, 2008 at 12:37 PM, Todd B. [email protected]
wrote:
ingredient varchar not null primary key
);insert into food values (“garlic”);
insert into measurements (“clove”);
Oops, there was supposed to be a values after measurements there. The
point still stands, though.
On Sun, 2008-05-25 at 22:29 +0900, Will P. wrote:
If the shoe fits. I would use SQLite more if it had proper relational
algebra under its hood.Would you mind explaining what you mean my that?
One example is that SQLite uses a very different typing system. In an
RDBMS (for SQL and every other definition of “relational” that I’m aware
of), every attribute has an associated type, and type checking is done
at the time the expression (SQL statement) is compiled.
In SQLite, you can store values of different types in the same attribute
in different tuples. This leaves us with the following undesirable
options:
If we choose #1, we end up with a language more like PHP, where values
are cast implicitly until it finds some way to return a result. This
completely circumvents type constraints, and it’s easy to end up getting
a garbage result, and passing that garbage along through a series of
other operators until the source of the problem is thoroughly obscured.
If we choose #2, we introduce runtime errors that depend on the actual
data we have stored in the database. We can test the application and get
no errors for anyone, and then when we put it into production someone
may put some data of some type that is not supported by the operators
we’re using for our queries. That may cause errors in many queries
throughout the system.
Both of these options are really just mechanisms to allow errors to
propagate further before they are caught. I think it’s much better to
catch errors early, personally.
I have nothing against SQLite, in fact I think it’s pretty good in some
ways, but I don’t consider it to be a relational database.
Regards,
Jeff D.
On Sun, May 25, 2008 at 12:37 PM, Todd B. [email protected]
wrote:
create table preparation (
measurement not null references measurements (measurement),
ingredient not null references food (ingredient),
primary key (measurement, ingredient)
);
Even worse, I missed the required type with measurement and ingredient
here with no error! which means I wouldn’t be able to migrate this to
another database.
Todd
On Sun, May 25, 2008 at 2:17 PM, Bill K. [email protected] wrote:
What actually happened there? Is it that SQLite added the space
on purpose because it noticed “garlic” didn’t satisfy the
“references measurements (measurement)” clause?
I don’t think so, because, even though I could repeat it, I could add
another row, and then it would output correctly.
Or is the space just some artifact of its output formatting that
doesn’t relate to the data?
Maybe that. I’ll play around a little. I seem to remember SQLite
documentation claiming the software would comply with SQL standards up
to a point, but to play well with others decided to silently ignore
certain things that it wasn’t capable of.
Todd
From: “Todd B.” [email protected]
create table food (
primary key (measurement, ingredient)
);insert into food values (“garlic”);
insert into measurements (“clove”);
insert into preparation (measurement, ingredient) values (“garlic”, “clove”);
insert into preparation (measurement, ingredient) values (“clove”, “garlic”);
select * from preparation;=> garlic |clove (yes, the result has that space after garlic)
=> clove|garlic
What actually happened there? Is it that SQLite added the space
on purpose because it noticed “garlic” didn’t satisfy the
“references measurements (measurement)” clause?
Or is the space just some artifact of its output formatting that
doesn’t relate to the data?
Puzzled,
Bill
On Sat, 24 May 2008, Todd B. wrote:
On Thu, May 22, 2008 at 10:40 PM, John C. [email protected] wrote:
…and now am yet another happy SQLite user.
Soo so so much simpler.
If the shoe fits. I would use SQLite more if it had proper relational
algebra under its hood.
Yip, I was speaking, half tongue-in-cheek hence the smiley :-)) in the
subject line. There are many very valid reasons for using
postgressql…
But unless one or more of those reasons are biting you hard, the
simplicity of sqllite is a major win.
Starting with sqllite and moving to postgres sql as and when and if you
need to is not a bad strategy either.
John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand
John C. wrote:
But unless one or more of those reasons are biting you hard, the
simplicity of sqllite is a major win.
On the subject of sqlite (and tangentially ruby), and with all you smart
folks on the list, a question:
Does anyone know how to keep sqlite from going to disk so much, or is
that a necessary part of the locking mechanism? Running with strace, the
write() is immediately followed by fsync(). It keeps my disk very busy
for what should be cheap insert operations to the end of a table with no
indexes. Cpu usage is low too (and I’m using SQLite3::Database#prepare
from the sqlite3 gem, to keep query overhead low).
There is :memory: for an in-memory db, but then if you want multiple
processes to access it, I guess you need to write a dedicated server
process(?).
Not only is this slow, but also it could be a killer on our embedded
flash-based devices that can’t be rewritten forever.
Thanks for any advice…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs