Tom, Jan,
> This is completely pointless, AFAICS. If you don't know what table
> is to be selected from, then you can't do *any* semantic checking or
> planning in advance, so you might as well just do the entire processing
> at runtime. That's exactly what EXECUTE does. I don't see any
> functional advantage in an intermediate step between plpgsql's normal
> behavior (caching of query plans) and EXECUTE. If it bought some
> readability over constructing a query string for EXECUTE, then maybe,
> but dealing in table and column OIDs is not my idea of a pleasant or
> readable way to program ...
Well, given that between you and Jan you have addressed dynamic
querying, it seems that there is no point in tinkering further. Always
great to find that a problem has already been solved.
If I wasn't up to my hairline in behind-schedule projects, I'd offer to
write this up for the User's Manual. Actually, consider that a
medium-term commitment ... before the end of the year, I'll write a much
longer PL/pgSQL chapter which Jan can review & correct. (I think I'm in
a postion to do so, as the current app uses a large assortment of
PL/pgSQL functions as pseudo-middleware).
-Josh Berkus
--
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
