Here's how the query dispatcher is working (the published
spec is behind the times, Ben's not had time to bring it up
to date, sorry - like all of us he's a volunteer and has a
business to run and clients to server so has been busy):
"foo.xql" contains queries that are SQL92 compliant or would
be if they didn't have function calls within them (at the
moment we figure that an RDBMS must have a decent programmatic
language to support the OpenACS 4.x API).
"foo-oracle.xql" and "foo-postgresql.xql" contain queries
specific to each of these.
The query extractor tries to make some intellegent guesses about
where the queries should go. Something simple like:
"select * from foo"
Goes only into the "foo.xql" generic or SQL92 compliant query
file.
Something like:
"select * from foo, bar where foo.key = bar.key(+)"
gets one copy written into "foo.xql" with a "FIX ME OUTER JOIN"
comment. The outer join gets fixed with SQL92 compliant syntax
(because that's what Postgres supports). It doesn't belong in the
"foo-postgresql.xql" because when fixed it won't be PostgreSQL
specific. Any SQL92 RDBMS will accept the new query (i.e.
InterBase).
A second copy, the original oracle-specific query, gets written
into "foo-oracle.xql" - the query dispatcher will select the
Oracle-specific query instead of the generic or SQL92 compliant
query.
Then there are queries like direct PL/SQL calls that have no
equivalent in SQL92. A copy gets written to "foo-oracle.xql", and
a second copy gets written to "foo-postgres.xql" with a "FIX ME"
flag.
If there are cases where the query dispatcher isn't finding the
right query please let me know.
I tried to explain this in the query extractor's README_PORTERS
file, but of course I only wrote it a couple of days ago and
I wrote some more yesterday..
