Gavin Sherry wrote:
> I'm not sure that cached results is a direction postgres need move in. But
> if it does, I think this a better way to do it (given that I may have
> overlooked something) than modifying the function manager (argh!).
I actually had an anterior motive.
Your comment about caching not being a direction in which PostgreSQL needs to
move, says it all. The general rank and file seems to agree. I think caching
could speed up a number of things, certainly some of the stuff I have been
working on. I think it would be more likely to get some sort of caching from a
contrib project rather than to sway the core team.
IMHO modifying the function manager to allow the return of a full row, and a
"set of" full rows, answers a LOT of issues I have seen over the years with
PostgreSQL extensibility.
With a full row function API we can implement:
(1) Remote Queries
select remotequery(hostname, port, 'select * from foo');
(2) External queries
select mysqlquery(hostname, port, 'select * from foo');
(3) Cached queries
select cachedquery('select * from foo');
(4) Full text search
select ftssquery(hostname, port, 'word1 and word2 and word3 not word4');
Again, with full row functions, we could prototype/implement many advanced
features in PostgreSQL as contrib projects.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
