Re: Extended customizing, SQL functions,

>
> pgsql(at)mohawksoft(dot)com writes:
>
>> I agree completely with one caveat, when the best tool for the job lacks
>> a
>> feature what do you do?
>
> You're missing the point. The feature you want has nothing to do with
> relational databases. It has everything to do with in-memory
> non-transactional
> non-relational databases. These things exist but they're not postgres.
>
> Postgres just isn't the best tool for what you want to do.
>
> Try memcached or any of the other very fast non-persistent
> non-transactional
> in-memory databases. If you try to use postgres to do this you'll find --
> as
> you just did -- that you've bought a lot of overhead for things you don't
> want. Because it's not the appropriate tool.

That's the problem. It easy to say, in effect, this isn't the job of the
database. Yet, the information is based on what's in the database. It is
one of those ambiguous things that life is so anoyingly full of. It's
really data related, so it should be in the database, it's really the
application's place to do this, so it should be in the application.

When all is said and done, I would say it is "too" data related to be so
separated from the database. Remember, PostgreSQL was chosen for the vast
number of advantages, this is just one small issues.