Thanks for sending this out.
A couple of questions:
* Why did we abandon the tagging using number (1-5) and decide to go with
letters/words.
This seems more prone to error.
* Is the line # relative to the query? Like PGPORT_xx:3 for line #3 in the
query?
or is it the absolute line # in the file. If the later, I would suggest we
don't do
this because: 1) grep will give us the file/line#. 2) if lines are inserted
during the
tagging process or (merging w/ master), the line # will be wrong.
See below:
Vikram Rai wrote:
Hi,
We have started looking at the queries that need to be tagged.
In the initial stages of going through these queries we found a
couple of things and some ways we can tag them.
Keeping in mind the diversity and complexity of the some of the
queries we have divided them into four categories:
1. Queries that need to have minor changes to make them work in postgres.
For eg: It could be like adding an "as" clause for alias names etc.
We had a suggestion to tag them with the following comment where
ever the changes are necessary:
pgsql_c:xxx --> which is postgresql_comment:line number.
Why "c"? - seems arbitrary or at least I don't get it :)
2. Queries that need to be rewritten. We had gone through a couple
of them as we went along the list and found some queries that had to
be rewritten to give an exact result. For eg: queries on system catalogs
in oracle do not work in postgres.
we would be tagging such queries with the following comment:
pgsql_q:xxx --> which is postgresql_query:line number.
Why "q"? - seems arbitrary or at least I don't get it :)
3. Incase there are any db changes to accommodate a query using
Orafce, such queries would be tagged as:
pgsql_orafce:xxx --> which is postgresql_database_change:line number.
I'd like to have a convention where we're more specific. In addition to tagging as a #3,
and that we *might* leverage orafce, I'd like to tag it with what feature(s) in orafce
such as NVL, DECODE(), ..
Also, a query might be tagged as a #3 and not leverage orafce but require another
compatability measure such as a DB function or procedure. I'd like to account for this.
4. No changes required to the existing query. Works both on postgres
and oracle.
pgsql_ora:xxx --> which is works on both postgres and oracle:line
number.
Why "ora"? - seems arbitrary or at least I don't get it :)
These are just some initial thoughts and I am sure we will have some
additions to it down the road as we unfold some more of them. Do let me
know what you think.
Regards,
Vikram Rai
EnterpriseDB
------------------------------------------------------------------------
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
