postgres/perl, autocommit and BEGIN; COMMIT;

[cbbrowne-HInyCGIudOg at public.gmane.org]

> On Monday 31 May 2004 08:23, cbbrowne-HInyCGIudOg at public.gmane.org wrote:
> 
> > There are two usual approaches for dealing with invalid input:
> >
> > =A01. =A0Throw an error back to the application, or
> > =A02. =A0Take a wild guess at some alternative value, and use it instead.
> >
> > If you want data integrity of your database, 1. is the right answer.
> > MySQL does 2.
> 
> I had always thought the answer was:
> 
> 3. Never accept invalid input.

That's ideal; the challenge comes in that you may have lots of code out
there that accesses the data.

If the database does no data validation, then that mandates that
validation be spread deeply throughout your application.  If there is a
single function that accesses the database that does not do all
necessary validation, then you just created a route to corrupt the
contents of the database.

> If invalid input ever touches your db layer then your software has a
> large bug.

If you can come up with a way to guarantee that ALL the code throughout
ALL of a complex distributed application cannot be affected by invalid
input, then you have solved one of the Great Problems of Distributed
Computing.

> One of the main drawbacks that I found with mysql is that it doesn't
> support subselects, I found myself wanting that even on a relatively
> simple website ... it was easy enough to work around but still the
> subselect would have (probably) been more efficient (definitely from a
> code point of view).

Yeah, we have a "bug" open right now where there's a query someone needs
to do against a crufty MySQL database that would be easy to do as an SQL
query, if MySQL actually supported a reasonable subset of SQL.

But because it is "simpler," it's going to be necessary to submit a
development request to the development group, with all the associated
weeping and gnashing of teeth.

> I don't use postgresql because I've seen it eat ram and eat disk
> space.  I hear it may now do an automatic "VACUUM" (whatever that
> means) so perhaps the disappearing disk issue is solved.  I've used
> mysql since 1998 and have only had one case of corruption, that was
> due to a corrupt disk.

What do you mean?  *ALL* real database systems eat all of RAM;
PostgreSQL is actually pretty unusual in that it normally _doesn't_ do
that.

I'm one of the ones that was involved with developing "pg_autovacuum",
which does indeed go a long ways towards addressing the "disappearing
disk" issue.

> In future projects I may chose postgresql but more from licensing
> concerns than technical ones (I expect).  I'll probably also give
> something like sqlite a go, it's not like I'm trying to run a gun
> registry ;-)

Licensing issues are getting to be, well, a growing concern.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www.ntlug.org/~cbbrowne/wp.html
"A  ROUGH  WHIMPER  OF   INSANITY"  is  an  anagram  for  "INFORMATION
SUPERHIGHWAY".
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml