Please see comments inline and marked as Vik>> On Tue, Feb 24, 2009 at 9:00 PM, Jeff Ortel <[email protected]> wrote:
> 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. Vik >> We can definitely go with numbers. if we agree that they will be less prone to errors. > > * 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. > Vik>> They are relative to the query > > 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 :)Vik>> PGPORT(as > clause)? If we add this to every line in a query it will make it a lot > complicated. We can use a general clause for the whole query. We can put > PGPORT(as clause):xxx PGPORT(order by):xxx. Do let me know your thoughts. > > >> 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 :). Vik>> more or less the same thing i was trying to explain in #1 > > > >> 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(), .. > Vik>> ok that can be done. > > 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. > Vik >> will add it. > >> >> 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 :) > Vik >> any suggestions here? If a query works for both what other tagging > options can we use? > >> >> 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 >
_______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
