Thread: bug on to do list reproducable at version 9.0-801
Hello jdbc mailing list,
We are using: version 9.0-801
I found that the inconsistent behavior we were expariancing with getTablePrivileges, has been logged as a bug and listed on : http://jdbc.postgresql.org/todo.html
[bugs] ACLs have changed format since the parsing code was written. The code only supports 7.3 style ACLs. DatabaseMetaData methods like getTablePrivileges do not work correctly against later servers
I was wondering if there is a timeframe by which this issue would be resolved.
Thank you,
Sincerely,
Kasia
On 2012-02-08 02:31, Kasia Tuszynska wrote: > Hello jdbc mailing list, > > We are using: version 9.0-801 > > I found that the inconsistent behavior we were expariancing with > getTablePrivileges, has been logged as a bug and listed on : > http://jdbc.postgresql.org/todo.html > > *[bugs]* ACLs have changed format since the parsing code was written. The code > only supports 7.3 style ACLs. DatabaseMetaData methods like getTablePrivileges > do not work correctly against later servers > > I was wondering if there is a timeframe by which this issue would be resolved. > Indeed I wrote a patch to the acl parsing which I submitted some time ago <http://archives.postgresql.org/pgsql-jdbc/2011-08/msg00071.php>. Now that the git move has been successfully done, is there a chance that someone could review the patch at this point? A quick check against 9.1 worked fine, also. Regards, Jonas Sundman
I should have some time to look at this. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, Feb 9, 2012 at 2:17 AM, Jonas Sundman <jonas.sundman@thl.fi> wrote: > On 2012-02-08 02:31, Kasia Tuszynska wrote: >> >> Hello jdbc mailing list, >> >> We are using: version 9.0-801 >> >> I found that the inconsistent behavior we were expariancing with >> getTablePrivileges, has been logged as a bug and listed on : >> http://jdbc.postgresql.org/todo.html >> >> *[bugs]* ACLs have changed format since the parsing code was written. The >> code >> >> only supports 7.3 style ACLs. DatabaseMetaData methods like >> getTablePrivileges >> do not work correctly against later servers >> >> I was wondering if there is a timeframe by which this issue would be >> resolved. >> > > Indeed I wrote a patch to the acl parsing which I submitted some time ago > <http://archives.postgresql.org/pgsql-jdbc/2011-08/msg00071.php>. > > Now that the git move has been successfully done, is there a chance that > someone could review the patch at this point? > > A quick check against 9.1 worked fine, also. > > Regards, > > Jonas Sundman > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
Jonas, Thanks for the patch. I've had some time to look at it. One problem I am running into is creating a test case for it. Currently all of our test code is in the test.org.postgresql.... package(s) however I can't get access to one of the protected methods from there. I'm thinking we should move all of the test code into org.postgresql.... package and drop the test. This would give us the ability to create unit tests on more methods Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Thu, Feb 9, 2012 at 6:34 AM, Dave Cramer <pg@fastcrypt.com> wrote: > I should have some time to look at this. > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > On Thu, Feb 9, 2012 at 2:17 AM, Jonas Sundman <jonas.sundman@thl.fi> wrote: >> On 2012-02-08 02:31, Kasia Tuszynska wrote: >>> >>> Hello jdbc mailing list, >>> >>> We are using: version 9.0-801 >>> >>> I found that the inconsistent behavior we were expariancing with >>> getTablePrivileges, has been logged as a bug and listed on : >>> http://jdbc.postgresql.org/todo.html >>> >>> *[bugs]* ACLs have changed format since the parsing code was written. The >>> code >>> >>> only supports 7.3 style ACLs. DatabaseMetaData methods like >>> getTablePrivileges >>> do not work correctly against later servers >>> >>> I was wondering if there is a timeframe by which this issue would be >>> resolved. >>> >> >> Indeed I wrote a patch to the acl parsing which I submitted some time ago >> <http://archives.postgresql.org/pgsql-jdbc/2011-08/msg00071.php>. >> >> Now that the git move has been successfully done, is there a chance that >> someone could review the patch at this point? >> >> A quick check against 9.1 worked fine, also. >> >> Regards, >> >> Jonas Sundman >> >> -- >> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-jdbc
Interesting... Thanks Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Mon, Feb 13, 2012 at 12:03 PM, Bodor András <bodri.mh3@gmail.com> wrote: > Hi Dave, > > You can use java reflection, and with the setAccessible(boolean flag) > method of java.lang.reflect.Method you can invoke anything. > Andras > > >> Currently all of our test code is in the test.org.postgresql.... >> package(s) however I can't get access to one of the protected methods >> from there.
Hi Dave,
You can use java reflection, and with the setAccessible(boolean flag)
method of java.lang.reflect.Method you can invoke anything.
Andras
> Currently all of our test code is in the test.org.postgresql....
> package(s) however I can't get access to one of the protected methods
> from there.
... as long as you're not running with a SecurityManager, which pgjdbc cannot assume. Florent On Mon, Feb 13, 2012 at 6:03 PM, Bodor András <bodri.mh3@gmail.com> wrote: > Hi Dave, > > You can use java reflection, and with the setAccessible(boolean flag) > method of java.lang.reflect.Method you can invoke anything. > Andras > > >> Currently all of our test code is in the test.org.postgresql.... >> package(s) however I can't get access to one of the protected methods >> from there. > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Florent Guillaume <fg@nuxeo.com> wrote: > Bodor András <bodri.mh3@gmail.com> wrote: >> You can use java reflection, and with the setAccessible(boolean >> flag) method of java.lang.reflect.Method you can invoke anything. > ... as long as you're not running with a SecurityManager, which > pgjdbc cannot assume. Even when running its test suite? -Kevin
On Mon, 13 Feb 2012, Dave Cramer wrote: > Thanks for the patch. I've had some time to look at it. One problem I > am running into is creating a test case for it. > > Currently all of our test code is in the test.org.postgresql.... > package(s) however I can't get access to one of the protected methods > from there. Are you confusing protected with package private? Changing the test package won't magically give you access to a protected method. > I'm thinking we should move all of the test code into > org.postgresql.... package and drop the test. This would give us the > ability to create unit tests on more methods > The easier approach is just to make more internal methods public. Since everyone is really just dealing the standard java.sql interfaces, I don't think we'd really be risking over-exposing driver internals. Kris Jurka
On Mon, Feb 13, 2012 at 6:41 PM, Kris Jurka <books@ejurka.com> wrote: > On Mon, 13 Feb 2012, Dave Cramer wrote: >> Thanks for the patch. I've had some time to look at it. One problem I >> am running into is creating a test case for it. >> >> Currently all of our test code is in the test.org.postgresql.... >> package(s) however I can't get access to one of the protected methods >> from there. > > Are you confusing protected with package private? Changing the test > package won't magically give you access to a protected method. Actually it will :) Florent > >> I'm thinking we should move all of the test code into >> org.postgresql.... package and drop the test. This would give us the >> ability to create unit tests on more methods >> > > The easier approach is just to make more internal methods public. Since > everyone is really just dealing the standard java.sql interfaces, I don't > think we'd really be risking over-exposing driver internals. > > Kris Jurka > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
On Mon, Feb 13, 2012 at 6:32 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Florent Guillaume <fg@nuxeo.com> wrote: >> Bodor András <bodri.mh3@gmail.com> wrote: > >>> You can use java reflection, and with the setAccessible(boolean >>> flag) method of java.lang.reflect.Method you can invoke anything. > >> ... as long as you're not running with a SecurityManager, which >> pgjdbc cannot assume. > > Even when running its test suite? Indeed in that case it's not a problem. Florent -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Mon, Feb 13, 2012 at 12:59 PM, Florent Guillaume <fg@nuxeo.com> wrote: > On Mon, Feb 13, 2012 at 6:41 PM, Kris Jurka <books@ejurka.com> wrote: >> On Mon, 13 Feb 2012, Dave Cramer wrote: >>> Thanks for the patch. I've had some time to look at it. One problem I >>> am running into is creating a test case for it. >>> >>> Currently all of our test code is in the test.org.postgresql.... >>> package(s) however I can't get access to one of the protected methods >>> from there. >> >> Are you confusing protected with package private? Changing the test >> package won't magically give you access to a protected method. > > Actually it will :) > My test suggests it will as well. Moving the package shouldn't be that difficult as we wouldn't physically move the files, just change the package names and the way it is compiled. Dave
> > > > On Mon, Feb 13, 2012 at 12:59 PM, Florent Guillaume <fg@nuxeo.com> wrote: >> On Mon, Feb 13, 2012 at 6:41 PM, Kris Jurka <books@ejurka.com> wrote: >>> On Mon, 13 Feb 2012, Dave Cramer wrote: >>>> Thanks for the patch. I've had some time to look at it. One problem I >>>> am running into is creating a test case for it. >>>> >>>> Currently all of our test code is in the test.org.postgresql.... >>>> package(s) however I can't get access to one of the protected methods >>>> from there. >>> >>> Are you confusing protected with package private? Changing the test >>> package won't magically give you access to a protected method. >> >> Actually it will :) >> > > My test suggests it will as well. > > Moving the package shouldn't be that difficult as we wouldn't > physically move the files, just change the package names and the way > it is compiled. Actually I recant. The files do need to be moved. For some reason I thought they were in test.org.postgresql..... > > Dave
Kasia, I just pushed in a Jonas' patch for this, can you test it please ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Tue, Feb 7, 2012 at 7:31 PM, Kasia Tuszynska <ktuszynska@esri.com> wrote: > Hello jdbc mailing list, > > We are using: version 9.0-801 > > > > I found that the inconsistent behavior we were expariancing with > getTablePrivileges, has been logged as a bug and listed on : > http://jdbc.postgresql.org/todo.html > > > > [bugs] ACLs have changed format since the parsing code was written. The code > only supports 7.3 style ACLs. DatabaseMetaData methods like > getTablePrivileges do not work correctly against later servers > > > > I was wondering if there is a timeframe by which this issue would be > resolved. > > > > Thank you, > > Sincerely, > > Kasia
On 02/13/2012 02:03 PM, Dave Cramer wrote: > Jonas, > > Thanks for the patch. I've had some time to look at it. One problem I > am running into is creating a test case for it. > > Currently all of our test code is in the test.org.postgresql.... > package(s) however I can't get access to one of the protected methods > from there. > > I'm thinking we should move all of the test code into > org.postgresql.... package and drop the test. This would give us the > ability to create unit tests on more methods Dave, great to hear, apparently You did sort out the test case. I'll check it out and test it now that it's submitted, thanks, Jonas Sundman
Well we need a lot more testing on that. It should test current versions as well. I made the parseACL function public :( Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Tue, Feb 14, 2012 at 5:41 AM, Jonas Sundman <jonas.sundman@thl.fi> wrote: > On 02/13/2012 02:03 PM, Dave Cramer wrote: >> >> Jonas, >> >> Thanks for the patch. I've had some time to look at it. One problem I >> am running into is creating a test case for it. >> >> Currently all of our test code is in the test.org.postgresql.... >> package(s) however I can't get access to one of the protected methods >> from there. >> >> I'm thinking we should move all of the test code into >> org.postgresql.... package and drop the test. This would give us the >> ability to create unit tests on more methods > > Dave, > > great to hear, apparently You did sort out the test case. > > I'll check it out and test it now that it's submitted, > > thanks, > > Jonas Sundman
On Tue, 14 Feb 2012, Dave Cramer wrote: > Well we need a lot more testing on that. It should test current > versions as well. The problem with the test is that it doesn't do any verification of the results, it just confirms that the parsing doesn't throw an exception. Kris Jurka
On Tue, Feb 14, 2012 at 12:23 PM, Kris Jurka <books@ejurka.com> wrote: > > > On Tue, 14 Feb 2012, Dave Cramer wrote: > >> Well we need a lot more testing on that. It should test current >> versions as well. > > The problem with the test is that it doesn't do any verification of the > results, it just confirms that the parsing doesn't throw an exception. > > Kris Jurka Clearly but I wanted to get it tested by Kasia sooner than later. Once that happens I will add test cases Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca