Re: [JDBC] jdbc proxy server ...
* Marc G. Fournier [EMAIL PROTECTED] wrote: | | have a database behind a firewall ... we'd like to make connections | available to that machine through a machine outside of the firewall, so | that its a secure connection to the proxy, and in-secure from | proxy-database ... | | the 'clients' will be written in java ... What about tunneling your connections through ssh ? -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Couple of patches for jdbc driver
Quoting Bruce Momjian [EMAIL PROTECTED]: The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. The real problem is that I don't remember all the things we have fixed in jdbc since 7.1.2 version so I am telling people to get the CVS version even if I am not sure it is fixed in there. Isn't the changelog kept up to date anymore? Uh, CHANGELOG? :-) No, I haven't been doing that, figuring I would update it in the main release notes. However, I haven't started doing that yet, and in fact I don't think I know enough about jdbc to know how to describe the items. I am relying on my compile tests and the jdbc list members for assistance with patch evaluation. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Couple of patches for jdbc driver
Quoting Bruce Momjian [EMAIL PROTECTED]: The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. The real problem is that I don't remember all the things we have fixed in jdbc since 7.1.2 version so I am telling people to get the CVS version even if I am not sure it is fixed in there. Isn't the changelog kept up to date anymore? Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Re: Couple of patches for jdbc driver
Bruce, I can try to fill in whatever I can. Where is it? Can you fill in as much as you can? Uh, there is a CHANGELOG file in the top level jdbc directory. We usually don't list interface-specific changes in the release notes. Instead we update a CHANGELOG file in the directory for that interface. Can you do a 'cvs log' of the jdbc directory and update that file? Don't worry about the date because this will all be in 7.2. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[JDBC] Re: JDBC changes for 7.2... some questions...
Ned, I would only agree to this functionality if it where a backend function. By putting it in the front end, you now need to front end to understand the special function. (And then you we are likely going to have requests that this special function be available in all the front ends JDBC, ODBC, perl, etc.). For the front end to understand the function it needs to parse the SQL statement. Thus under your proposal every select statement needs to be parsed to see if one of the selected items is the special function. I strive to ensure that the jdbc code does not need to parse the SQL statements and understand the grammer of the SQL language. Since functions can appear in select lists, where clauses, orderbys, and even insert and update statements, you quickly end up with the client needing to reimplement the entire parser that is already in the backend. You could argue that this really could be special cased (i.e. it must be exactly 'select getInsertedOID()' case and whitespace makes a difference, but then all you really have is a kludge for a specific problem, not a framework to solve other similar problems. I would argue that a framework does exist to solve this and other problems and that framework is to add additional functions into the backend. Given that the JDBC driver already does provide the information via the getLastOID() method, we are really dealing with a small isolated problem here because of the use of a connection pool that doesn't let you get at that method. (Unfortunatly for you, it is the problem you are facing). In general I don't think the benefits of this feature (i.e. providing information that is currently available, except when using certain 3rd party connection pooling mechanisms) are worth the long term costs. If the function was implemented in the backend, I think it would be a good idea. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, it's not a new function on the server... I'm just trying to find a way to access the getInsertedOID() method in the statement object without having direct access to the statement object. (My use-case is when the JDBC driver is wrapped in a pooling manager, like PoolMan, it wraps all classes.) I wanted to catch the line 'select @@last_oid' which would return a result set with the single entry based on the results of the method call 'getInsertedOID' but some people didn't like the syntax. So, I'm seaking comments to see if there is a better syntax people like, as long as they don't mind the functionality. One option is the 'faking' of the function call on the server, which really isn't a good option in itself, but outside of my original 'catch' line, its all I got. What's your thoughts? Do you see the need for the functionality? Do you have a solution that I need? On 22-Aug-2001 Barry Lind wrote: I am assuming that this would be a new function in the server. Therefore this wouldn't be jdbc specific and would be available to all client interfaces. I don't see what this really has to do with JDBC. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so you're not opposed to the idea then, just the syntax. Does anyone oppose having this concept in the JDBC driver? And what syntax is acceptable? Could we just do 'select getInsertedOID()' which would break people who have functions called getInsertedOID() of course... On 21-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7gv5yiysnOdCML0URAq7qAJkBRhAcE9wctn7bUAv7UMwN3n9+nwCeJR4V ymYTw8l3f9WU4V5idFsibAE= =UQ2M -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7g+agiysnOdCML0URAvbvAJ9GO/spmwQYZessjk4IenhtPuguSwCdHRQN xH+tnGqKpmg/UOSnxOevek0= =pcr+ -END PGP SIGNATURE- ---(end of
Re: [JDBC] Re: Couple of patches for jdbc driver
On Thu, 23 Aug 2001 10:46:18 -0400 (EDT), Bruce Momjian wrote: Uh, CHANGELOG? :-) No, I haven't been doing that, figuring I would update it in the main release notes. However, I haven't started doing that yet, and in fact I don't think I know enough about jdbc to know how to describe the items. I think you should require us to post a release note with every patch. That would make great documentation for reviewing and evaluating the patch as well. Regards, René Pijlman ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[JDBC] Re: [PATCHES] JDBC patch for util.Serialize and jdbc2.PreparedStatement
On Thu, 23 Aug 2001 14:37:27 -0400, you wrote: a patch [...] that fixes the ability to serialize a simple java class into a postgres table. The current cvs seems completely broken in this support, so the patch puts it into working condition, granted that there are many limitations with serializing java classes into Postgres. I would appreciate it if you would explain to us a little more what does and doesn't work before and after applying this patch. [jdbc-list added to the CC] Regards, René Pijlman ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I like your function name, get_last_returned_oid(). That works for me. On 23-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: Should the backend support the function getLastInsertedOID() or even getLastInsertedPrimaryKey() (or both)? I don't think you have any chance of doing the latter --- for one thing, how are you going to declare that function's return type? But the former seems doable and reasonable to me: whenever an OID is returned to the client in an INSERT or UPDATE command result, also stash it in a static variable that can be picked up by this function. Please pick a more SQL-friendly (ie, case insensitive) naming convention, though. And note that it'd apply to both INSERT and UPDATE. Maybe get_last_returned_oid() ? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hWGbiysnOdCML0URAkqAAJ9Liv8VS+CPMYozG1q1tuy7vGLuEACfUJRM Hdbns8MxyOVgurx5ztV8YZU= =BbF3 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]