Обсуждение: Commit ad2a4ae causing more damages than fixes in regression tests
Hi Saito-san, What is the purpose of commit ad2a4ae done yesterday? Regression tests are failing exactly because of that. I imagine that you are running your tests on a 9.2 server or older 9.3 because the NOTICE message showing PRIMARY KEY creation has been changed to DEBUG level in 9.3. For simplicity's sake, I think that we should make the regression tests only compatible with the latest versions of Postgres. We could still use some alternate output but what's the point except complicating the work of maintainers? Hence, I think that this change should be reverted. Or if you guys think that we need to make regression tests compatible down to 7.4 we should have alternate result outputs. I'd personally vote for reverting this commit to simplify maintenance as this project does not have stable branches. Regards, -- Michael
Hi Michael-san. thank quick inspection.! I've noticed it in some tests too. However, I think that it must be fully considered the production environment psqlODBC have been supported some versions. Therefore, I have a message level set to it. What do you think? again, I'm sorry not have a margin time.... Regards, Hiroshi Saito (2014/05/15 15:46), Michael Paquier wrote: > Hi Saito-san, > > What is the purpose of commit ad2a4ae done yesterday? Regression tests > are failing exactly because of that. I imagine that you are running > your tests on a 9.2 server or older 9.3 because the NOTICE message > showing PRIMARY KEY creation has been changed to DEBUG level in 9.3. > > For simplicity's sake, I think that we should make the regression > tests only compatible with the latest versions of Postgres. We could > still use some alternate output but what's the point except > complicating the work of maintainers? Hence, I think that this change > should be reverted. Or if you guys think that we need to make > regression tests compatible down to 7.4 we should have alternate > result outputs. > > I'd personally vote for reverting this commit to simplify maintenance > as this project does not have stable branches. > > Regards, >
On Thu, May 15, 2014 at 11:28 PM, Hiroshi Saito <hiroshi@winpg.jp> wrote: > Hi Michael-san. > > thank quick inspection.! > > I've noticed it in some tests too. However, I think that it must be fully > considered the production environment psqlODBC have been supported some > versions. Therefore, I have a message level set to it. > What do you think? Looks good for the test sampletables... However, I am still getiing the following diff for catalogfunctions on a 9.4 server... *** /Users/mpaquier/git/pgodbc/test/expected/catalogfunctions.out Fri May 16 08:13:36 2014 --- /Users/mpaquier/git/pgodbc/test/results/catalogfunctions.out Fri May 16 08:14:10 2014 *************** *** 186,196 **** contrib_regression public testtab1 _SYSTEM UPDATE YES contrib_regression public testtab1 _SYSTEM DELETE YES contrib_regression public testtab1 _SYSTEM REFERENCES YES - contrib_regression public testtab1 _SYSTEM INSERT YES - contrib_regression public testtab1 _SYSTEM SELECT YES - contrib_regression public testtab1 _SYSTEM UPDATE YES - contrib_regression public testtab1 _SYSTEM DELETE YES - contrib_regression public testtab1 _SYSTEM REFERENCES YES Result set: contrib_regression public testtab1 TABLE contrib_regression public testtab_fk TABLE --- 186,191 ---- ====================================================================== -- Michael
Hi Michael-san. (2014/05/16 8:16), Michael Paquier wrote: > Looks good for the test sampletables... Ok,Thanks. > > However, I am still getiing the following diff for catalogfunctions on > a 9.4 server... Um, it has not been released yet, and it is not in my test case.:-( I don't know whether desire it now. However,require in the future. Regards, Hiroshi Saito
Saito-san, On Fri, May 16, 2014 at 11:37 PM, Hiroshi Saito <hiroshi@winpg.jp> wrote: > Um, it has not been released yet, and it is not in my test case.:-( > I don't know whether desire it now. However,require in the future. After some more testing, I am seeing that the diffs in test catalogfunction that you have introduced with commit ad2a4ae are reproducible down to 8.4 (didn't go further down): *** /Users/ioltas/git/pgodbc/test/expected/catalogfunctions.out Fri May 16 08:13:36 2014 --- /Users/ioltas/git/pgodbc/test/results/catalogfunctions.out Mon May 19 11:25:36 2014 *************** *** 186,196 **** contrib_regression public testtab1 _SYSTEM UPDATE YES contrib_regression public testtab1 _SYSTEM DELETE YES contrib_regression public testtab1 _SYSTEM REFERENCES YES - contrib_regression public testtab1 _SYSTEM INSERT YES - contrib_regression public testtab1 _SYSTEM SELECT YES - contrib_regression public testtab1 _SYSTEM UPDATE YES - contrib_regression public testtab1 _SYSTEM DELETE YES - contrib_regression public testtab1 _SYSTEM REFERENCES YES Result set: contrib_regression public testtab1 TABLE contrib_regression public testtab_fk TABLE --- 186,191 ---- Could you provide the configuration files you have been using for your tests? I am afraid that I am not able to understand why you are seeing such diffs. Heikki, are you noticing that? This may be as well a bug in the ODBC code, it is somewhat weird to see two times the same permission entries for the same table (testtab1) when calling SQLTablePrivileges. -- Michael
On 05/19/2014 05:32 AM, Michael Paquier wrote: > Saito-san, > > On Fri, May 16, 2014 at 11:37 PM, Hiroshi Saito <hiroshi@winpg.jp> wrote: >> Um, it has not been released yet, and it is not in my test case.:-( >> I don't know whether desire it now. However,require in the future. > After some more testing, I am seeing that the diffs in test > catalogfunction that you have introduced with commit ad2a4ae are > reproducible down to 8.4 (didn't go further down): > *** /Users/ioltas/git/pgodbc/test/expected/catalogfunctions.out Fri > May 16 08:13:36 2014 > --- /Users/ioltas/git/pgodbc/test/results/catalogfunctions.out Mon > May 19 11:25:36 2014 > *************** > *** 186,196 **** > contrib_regression public testtab1 _SYSTEM UPDATE YES > contrib_regression public testtab1 _SYSTEM DELETE YES > contrib_regression public testtab1 _SYSTEM REFERENCES YES > - contrib_regression public testtab1 _SYSTEM INSERT YES > - contrib_regression public testtab1 _SYSTEM SELECT YES > - contrib_regression public testtab1 _SYSTEM UPDATE YES > - contrib_regression public testtab1 _SYSTEM DELETE YES > - contrib_regression public testtab1 _SYSTEM REFERENCES YES > Result set: > contrib_regression public testtab1 TABLE > contrib_regression public testtab_fk TABLE > --- 186,191 ---- > > Could you provide the configuration files you have been using for your > tests? I am afraid that I am not able to understand why you are seeing > such diffs. Heikki, are you noticing that? Yep. The expected output in git at the moment is just wrong. > This may be as well a bug in the ODBC code, it is somewhat weird to > see two times the same permission entries for the same table > (testtab1) when calling SQLTablePrivileges. Yeah. If there is a configuration that actually produces that output, then it sure looks like a bug in the code. - Heikki