> Mohawksoft,
>
>> Actually that are not involved with transactions in any way.
>>
>> There classes of problems in which proper ACID implementation is not
>> nessisary. In fact, there are subclasses within a larger system that
>> need
>> not have the overhead imposed by transactions.
>
> Hmmm, wait, are you implementing this, or is Jonathan?
>
> As a database developer who would use this or a similar feature, I do not
> agree that the lack of transactionality is a benefit. Quite the
> contrary.
> Imagine this scenario, once we have error-trapping in place for 8.1
> (pardon
> the syntax if it's off the proposal, I think you'll see the point anyway):
[snip -- example]
Your example makes sense if you think that you'll only be using this in
the SQL environment.
One of the most common SQL database applications is as the backend of some
higher level system, like a web site. In these systems, ususlly done in
Java, PHP, or heaven help us, .NET, you have multiple front end machine
communicating with a SQL database backend.
These systems use the database as the main data server. The overall
scalability of their system is based on the scalability of the database.
At some point, you'll max out the DB and be stuck. The shared variables
module is designed to allow you to scale better by allowing you to cheapy
maintain data.
So, rather than call this:
select sum(field) from mytable;
or
update mytable_summary set field = field + n;
You can do this:
select addshared('mytable', n);
Now, in Java or PHP, you'd do something like this:
somefunc()
{ if(sql.exec(...)) { // Worked sql.exec("select addshared('mytable', n)"); }
}
OK, now you're going to say, why not use a different system for the
caching? As I said in a different post, the more systems you glue
together, the more complicated the bigger system gets. The more
complicated it gets, the less reliable it gets. Besides, this is data
you're gonna use with the data in PostgreSQL, so why not provide an
extension for it?
