Обсуждение: Documentation problem with LargeObjectManager
In http://jdbc.postgresql.org/documentation/82/binary-data.html it says that the return from LargeObjectManager.create is a long, but the actual code seems to return an int, which is also what the read and write methods seem to want as OID. Is this a code or a documentation problem? The docs are the same for 8.3. David
David Goodenough wrote: > In http://jdbc.postgresql.org/documentation/82/binary-data.html it says that > the return from LargeObjectManager.create is a long, but the actual code > seems to return an int, which is also what the read and write methods seem > to want as OID. Is this a code or a documentation problem? The docs are > the same for 8.3. > The docs refer to createLO which does return long, not create which returns int. OID is unsigned int, but since Java doesn't have unsigned types we need to use long. This was added relatively recently, as the original API didn't consider that requirement, so that's why we have a slight mix of function signatures. In any case you should be using the long versions and the int versions should be marked as deprecated. Kris Jurka
On Monday 31 March 2008, Kris Jurka wrote: > David Goodenough wrote: > > In http://jdbc.postgresql.org/documentation/82/binary-data.html it says > > that the return from LargeObjectManager.create is a long, but the actual > > code seems to return an int, which is also what the read and write > > methods seem to want as OID. Is this a code or a documentation problem? > > The docs are the same for 8.3. > > The docs refer to createLO which does return long, not create which > returns int. OID is unsigned int, but since Java doesn't have unsigned > types we need to use long. This was added relatively recently, as the > original API didn't consider that requirement, so that's why we have a > slight mix of function signatures. In any case you should be using the > long versions and the int versions should be marked as deprecated. > > Kris Jurka OK, my problem was that the 8.2 JDBC driver (which is the most recent in Debian) did not have the long versions. I have now downloaded the jar file from the postgresql web site and I see the long versions. However this has shown up another problem. The createLO shown in the docs has an arguement, but the JDBC4 jar file says that this createLO is deprecated, and I presume I should use the no arguement version. David
On Mon, 31 Mar 2008, David Goodenough wrote: > However this has shown up another problem. The createLO shown in the > docs has an arguement, but the JDBC4 jar file says that this createLO is > deprecated, and I presume I should use the no arguement version. > I don't see that here: http://jdbc.postgresql.org/documentation/publicapi/org/postgresql/largeobject/LargeObjectManager.html Kris Jurka
On Monday 31 March 2008, Kris Jurka wrote: > On Mon, 31 Mar 2008, David Goodenough wrote: > > However this has shown up another problem. The createLO shown in the > > docs has an arguement, but the JDBC4 jar file says that this createLO is > > deprecated, and I presume I should use the no arguement version. > > I don't see that here: > > http://jdbc.postgresql.org/documentation/publicapi/org/postgresql/largeobje >ct/LargeObjectManager.html > > Kris Jurka It may not be in the documentation, but the compiler reports it. David
On Mon, 31 Mar 2008, David Goodenough wrote: > It may not be in the documentation, but the compiler reports it. > I'm not sure what you're seeing. Take a look at the source code for the 8.2 driver series [1]. In LargeObjectManager circa line 238 you can see that createLO(int) is not marked deprecated. Kris Jurka [1] http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/largeobject/LargeObjectManager.java?annotate=1.20.2.1
On Monday 31 March 2008, Kris Jurka wrote: > On Mon, 31 Mar 2008, David Goodenough wrote: > > It may not be in the documentation, but the compiler reports it. > > I'm not sure what you're seeing. Take a look at the source code for the > 8.2 driver series [1]. In LargeObjectManager circa line 238 you can see > that createLO(int) is not marked deprecated. > > Kris Jurka > > [1] > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/larg >eobject/LargeObjectManager.java?annotate=1.20.2.1 Looks like it might have been a typo on my part. The create methods are now deprecated, but the createLO methods are not. David