Bruce Momjian wrote:
Jan Pazdziora wrote:
On Thu, Jan 29, 2009 at 11:45:42PM -0500, Bruce Momjian wrote:
Sorry, maybe I wasn't clear. On this page:
https://fedorahosted.org/spacewalk/wiki/PostgresTechnicalApproach
we list the four query types:
1. work unchanged in both Oracle and Postgres
2. can be rewritten to work on both databases, e.g. ANSI joins,
CURRENT_TIMESTAMP, CASE instead of decode(), COALESCE instead of NVL()
3. (same) but requires db changes, e.g. add compatibility functions
from Orafce
4. need to create a Postgres-specific version of the query
Previously I mentioned decode() in #3, but I have now updated the wiki
to mention the use of CASE intead of decode, etc. I think we should be
doing #3 only if we can't easily rewrite the query to be a #2.
Any change which requires #2 will need to be QA'ed in Oracle /
Satellite as well.
After the pg port, we'll always have to QA satellite on both databases
anyway ...
While it is a noble goal to have the codebase in
pure ANSI syntax, milestone-wise it will be much more feasible to
start with compatibility layer (#3) first and not depend on #2.
Including for DECODE.
Well, the wiki states we should try to make queries be the lowest
numbered item possible:
https://fedorahosted.org/spacewalk/wiki/PostgresTechnicalApproach
If we want to avoid #2 and make make more #3 and #4s, fine, but we need
to decide this as a group. Keep in mind if we decide we want no #2, we
are going to have a lot more #4 duplicate queries, which I thought we
wanted to avoid.
Yes, we really want to avoid having duplicate queries as this will be a
maintenance nightmare.
Whether this is done via 1) compatibility layer or 2) migrating the
queries to ANSI SQL or both is another question. The advantage of doing
it in the compatibility layer is (maybe) lower risk when running on
Oracle. But, since we know there are many queries that must be
rewritten (for example: queries with the oracle (+) syntax for outer
joins) anyway, why not just do the right thing now and get it over with
while we're committed to spending the $$ and time to do this? If
satellite is going to become a multi-database application, shouldn't the
application code be as database agnostic as possible?
After the tagging process we need to count the #2 vs #3 queries (as
planned) and then decide which strategy make sense for us. Without
these numbers, we'll just be guessing the risk/reward of taking either
approach.
Basically, if we make any #2s, the Oracle port is going to have to be
retested, so why try to minimize #2 changes?
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
