A C client for memcached

[Sean Chittenden]

> Are your memcached functions for PostgreSQL anywhere near portable?   
> I'd love
> to play with them.

It's on my list of things to do.  I have my own half-baked programming 
language and in my PostgreSQL code, I used the string handling from my 
language instead of C's routines.  Once I decouple them, I will most 
certainly open them up.  Essentially what it does is, if one doesn't 
exist, it establishes a connection.  On updates it fires off a replace 
to the appropriate server.  On delete, it issues a delete.  I don't do 
anything on INSERTs that way it only gets loaded into the cluster when 
the data is actually read by the client.

I'm finding that on tables that pertain to signups, I'm incuring an 
unnecessary hit to the database.  Once a user signs up, they're going 
to proceed login 99% of the time... why not preempt the lookup when you 
know it's coming?  Right now I handle caching on the login page, but 
I'm finding that I might as well throw the object into the cache on 
signup.  Anyway, to handle that case, I'm likely going to create an 
INSERT trigger/routine, but haven't done so yet.  Once I do though, 
I'll consider it a nicely rounded out PostgreSQL library that I'll 
likely want to post on pgfoundry or have included in the base install 
as a contrib module.  *shrug*

I'm dying for some COMMIT triggers, 'cause as things stand, I've set 
these up as AFTER tiggers, but bogus and I'm pre-caching data before 
the transaction is committed.  A user could signup and *not* complete 
the transaction... but would log in.  Thankfully I've only had one 
instance of this in the wild and my code removes any keys if the 
transaction isn't successful.  It'd be nice to have a trigger list for 
on commit and on rollback explicitly for this reason.

Don't hesitate to nag me, if you don't see me making progress on it.  
:-]  -sc

-- 
Sean Chittenden