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. 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.
Basically, if we make any #2s, the Oracle port is going to have to be
retested, so why try to minimize #2 changes?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
