[JDBC] JDBC patch for util.Serialize and jdbc2.PreparedStatement (attempt #2)
I submitted an "attempt#2" or "take 2" of a patch to fix the util.Serialize and jdbc2.PreparedStatement classes so that the serializing of a java class into the database works more that it did before. The code to "serialize" a java class instance into a table in the database has existed in the jdbc source code for a long time according to the comments I read in the source code. However, when I tried to use this stuff it didn't work at all. So, I hacked on it some and made some relatively simple fixes and got it to work. There lots of restrictions on what java class can be serialized and how you need to write it though: see the source code comments for the Serialize.java (see pgsql-patches list or the unapplied patches list) file in my patch or in cvs if it is applied. The serialize code executes as a result of calling jdbc2.PreparedStatement setObject(int, Object), where Object is some unrecognized type. setObject defaults to trying to "serialize" an Object if no if/else case matches first. This results in an instance of Serialize being initialized for the class of Object and in Serialize's constructor, it queries pg_class to find a relname that matches the name of the java class. If found, the table is attempted to be used to store or fetch instances of the java class. This table will not exist unless it is first initialized once by calling Serialize.create(conn,Object) first ( unless by some freak chance a table with the right name already existed and is used unintentionally!). Again, read the source code comments in Serialize.java. Because there are so many restictions/limitations about it, it might not be all that useful in its present form. A better serialize method might be to use the standard java Serializable interface stuff more to get a binary string representation of the class instance and store it in the database in whatever kind of field postgres can hold a binary string in (hopefully something other than a large object). Whatever its limitations, it might be nice for some use if tested more and debugged enough. I don't claim it to be bug free! There is some code in the Serialize create method that attempts to recursively convert fields of a class into a bunch of tables, but I did not write that code nor test it. Making it work involved using a table as a data type: something that postgres supports, but not completely. The tablerow-as-type type has no support operators or functions for even simple things like casting or comparing, so it can't do anything but serve as a type identifier. An oid field is still needed along with this tabletype id field. The oid number and the number value stored in a tablero-type field are the same; they are just different datatypes: one is of type oid, which you can do useful things with, and the other of type mytable or whatever which postgres won't let you much of anything useful with. Like the old comment in Serialize.java said, it is complex to explain, but actually it is simple. On Thursday 23 August 2001 17:37, Rene Pijlman wrote: > 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Hmm OIDs would be optional in 7.2. > Is it known(announced) to pgsql-jdbc list ? Doesn't seem particularly relevant to this issue though. An application that's using OIDs to identify rows would certainly not choose to create its tables without OIDs. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
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 Hmm OIDs would be optional in 7.2. Is it known(announced) to pgsql-jdbc list ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC ch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-Aug-2001 Rene Pijlman wrote: > What should the semantics be exactly? > > How about the multiple INSERT's i've been reading about on > hackers? ... Only the OID of the last row inserted by the > statement? > > How about an UPDATE statement that updates multiple rows? Well, here's my thoughts on this... The functionality would be that the very last inserted or updated OID would be stored in this static variable that is associated with the connection/session. So, in multiple inserts or updates, it is the last oid affect where this variable would be updated. > How about triggers that insert/update extra rows? ... Only the > OID of the row directly inserted by the client statement? It would be the last updated request caused by any insert or update, regardless of if its a trigger, preparedStatement, etc. > How about Large Objects? Should inserting or updating a large > object affect getLastInsertedOID()? Yes. > I assume this OID would be associated with a client connection. > Is this going to work with client side connection pooling? It must... that's the reason for this. Specifically, the JDBC driver has a method in it that is called getInsertedOID() which provides the last sucessfully inserted row's OID. This is specific to the driver, and JDBC pooling techniques do not allow access to this method. (It's not part of the JDBC spec) So, to make this data accessable to the users in a pooling condition, the call "select getLastOID()" needs to return the OID that is specific to the session. In Java, pooling techniques generally are aquired, then released, as dependant on the client or timeout procedures, and not randomly used for individual queries. (Mostly because of the need for the same driver during a transaction that takes multiple queries.) > How about transaction semantics? INSERT row 1, Commit, INSERT > row 2, Rollback... what should getLastInsertedOID() return? Can > it, with a static variable? Good question. I'd start with rollback not affecting this value. Reason being that this function would be mostly used in a transaction anyways. I would not object to making this method only available during a transaction block if that helps. 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 iD8DBQE7hWEwiysnOdCML0URAk3xAJ92nYoy22mP4Yk8xk53vojlF42w5gCfbnZf uexoQ9yqexctXvQM0yx+g2Y= =yK6n -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC ch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-Aug-2001 Tom Lane wrote: >> I assume this OID would be associated with a client connection. >> Is this going to work with client side connection pooling? > > Good point. Will this really get around the original poster's problem?? It must. If transactions are on, any pooling mechanism needs to continue to use that connection for the client unti the transaction is done. (Most require the client to either tell the pool manager the connection is no longer need, via a close() call, or a pool-manager specific call, precisely because the client needs it to complete the transaction. My feeling is that if this is a problem, then this method call may need to be limited to the transaction context, but I hope that this is not the case. Most pool managers (and I'm only speaking about Java here) require some activity on the client to give up the connection, either directly or indirectly. 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 iD8DBQE7hYNRiysnOdCML0URAre3AJ94x/4mfeaJX3IQjRtyTWafeaR/BgCeIB4V liQyRjblBSuX38R0kq+NvVw= =ltfC -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
Rene Pijlman <[EMAIL PROTECTED]> writes: > On Thu, 23 Aug 2001 14:44:19 -0400, you wrote: >> 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. > What should the semantics be exactly? Just the same as the command result string. > How about the multiple INSERT's i've been reading about on > hackers? ... Only the OID of the last row inserted by the > statement? No OID is returned when multiple rows are inserted or updated. I'd say that should be the semantics of this function, too. > How about JDBC batchExecute() when it performs multiple > INSERT/UPDATE's? By definition, this is a backend function. It cannot know anything of JDBC. > I assume this OID would be associated with a client connection. > Is this going to work with client side connection pooling? Good point. Will this really get around the original poster's problem?? regards, tom lane ---(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] 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. Uh, I guess. We don't require that for others. We go through the list of items before each release. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] Re: Accessing multiple Databases at the same time
[join tables in different databases] >Can you really do this?! that would be great! how is it done? I understand >accessing multiple databases, but I can't figure out how I would do a JOIN >across them. Apparently you are actually awake when you read this list, I wasn't :-) OTOH, if the PostgreSQL engine can do, so can you... Regards, René Pijlman ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[JDBC] patch for JDBC1 build problems
Attached is a patch to fix the current issues with building under jdbc1.
This patch moves the logic that looks up TypeOid, PGTypeName, and
SQLTypeName from Field to Connection. It is moved to connection since
it needs to differ from the jdbc1 to jdbc2 versions and Connection
already has different subclasses for the two driver versions. It also
made sense to move the logic to Connection as some of the logic was
already there anyway.
thanks,
--Barry
*** ./src/interfaces/jdbc/org/postgresql/Connection.java.orig Wed Aug 22 02:56:24
2001
--- ./src/interfaces/jdbc/org/postgresql/Connection.javaWed Aug 22 03:08:37
2001
***
*** 69,79
// New for 6.3, salt value for crypt authorisation
private String salt;
! // This is used by Field to cache oid -> names.
! // It's here, because it's shared across this connection only.
! // Hence it cannot be static within the Field class, because it would then
! // be across all connections, which could be to different backends.
! public Hashtable fieldCache = new Hashtable();
// Now handle notices as warnings, so things like "show" now work
public SQLWarning firstWarning = null;
--- 69,78
// New for 6.3, salt value for crypt authorisation
private String salt;
! // These are used to cache oids, PGTypes and SQLTypes
! private static Hashtable sqlTypeCache = new Hashtable(); // oid -> SQLType
! private static Hashtable pgTypeCache = new Hashtable(); // oid -> PGType
! private static Hashtable typeOidCache = new Hashtable(); //PGType -> oid
// Now handle notices as warnings, so things like "show" now work
public SQLWarning firstWarning = null;
***
*** 1108,1112
--- 1107,1192
{
return (getDBVersionNumber().compareTo(ver) >= 0);
}
+
+
+ /**
+* This returns the java.sql.Types type for a PG type oid
+*
+* @param oid PostgreSQL type oid
+* @return the java.sql.Types type
+* @exception SQLException if a database access error occurs
+*/
+ public int getSQLType(int oid) throws SQLException
+ {
+ Integer sqlType = (Integer)typeOidCache.get(new Integer(oid));
+
+ // it's not in the cache, so perform a query, and add the result to the cache
+ if(sqlType==null) {
+ ResultSet result = (org.postgresql.ResultSet)ExecSQL("select typname from
+pg_type where oid = " + oid);
+ if (result.getColumnCount() != 1 || result.getTupleCount() != 1)
+ throw new PSQLException("postgresql.unexpected");
+ result.next();
+ String pgType = result.getString(1);
+ Integer iOid = new Integer(oid);
+ sqlType = new Integer(getSQLType(result.getString(1)));
+ sqlTypeCache.put(iOid,sqlType);
+ pgTypeCache.put(iOid,pgType);
+ result.close();
+ }
+
+ return sqlType.intValue();
+ }
+
+ /**
+* This returns the java.sql.Types type for a PG type
+*
+* @param pgTypeName PostgreSQL type name
+* @return the java.sql.Types type
+*/
+ public abstract int getSQLType(String pgTypeName);
+
+ /**
+* This returns the oid for a given PG data type
+* @param typeName PostgreSQL type name
+* @return PostgreSQL oid value for a field of this type
+*/
+ public int getOID(String typeName) throws SQLException
+ {
+ int oid = -1;
+ if(typeName != null) {
+ Integer oidValue = (Integer) typeOidCache.get(typeName);
+ if(oidValue != null) {
+ oid = oidValue.intValue();
+ } else {
+ // it's not in the cache, so perform a query, and add the result to the
+cache
+ ResultSet result = (org.postgresql.ResultSet)ExecSQL("select oid from
+pg_type where typname='"
+ + typeName + "'");
+ if (result.getColumnCount() != 1 || result.getTupleCount() != 1)
+ throw new PSQLException("postgresql.unexpected");
+ result.next();
+ oid = Integer.parseInt(result.getString(1));
+ typeOidCache.put(typeName, new Integer(oid));
+ result.close();
+ }
+ }
+ return oid;
+ }
+
+ /**
+* We also need to get the PG type name as returned by the back end.
+*
+* @return the String representation of the type of this field
+* @exception SQLException if a database access error occurs
+*/
+ public String getPGType(int oid) throws SQLException
+ {
+ String pgType = (String) pgTypeCache.get(new Integer(oid));
+ if(pgType == null) {
+ getSQLType(oid);
+ pgType = (String) pgTypeCache.get(new Integer(oid));
+ }
+ return pgType;
+ }
+
}
*** ./src/interfaces/jdbc/org/postgresql/Field.java.origWed Aug 22 02:56:24
2001
--- ./src/interfaces/jdbc/org/postgresql/Field.java Wed Aug 22 03:12:33 2001
***
*** 12,28
*/
public class Field
{
! public int length; // Internal L
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
On Thu, 23 Aug 2001 14:44:19 -0400, you wrote: >Ned Wolpert <[EMAIL PROTECTED]> writes: >> Should the backend support the function getLastInsertedOID()? > >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. What should the semantics be exactly? How about the multiple INSERT's i've been reading about on hackers? ... Only the OID of the last row inserted by the statement? How about an UPDATE statement that updates multiple rows? How about JDBC batchExecute() when it performs multiple INSERT/UPDATE's? ... Only the OID of the last UPDATE or INSERT statement in the batch? How about triggers that insert/update extra rows? ... Only the OID of the row directly inserted by the client statement? How about Large Objects? Should inserting or updating a large object affect getLastInsertedOID()? I assume this OID would be associated with a client connection. Is this going to work with client side connection pooling? How about transaction semantics? INSERT row 1, Commit, INSERT row 2, Rollback... what should getLastInsertedOID() return? Can it, with a static variable? 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]
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
Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
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])
[JDBC] New backend functions? [was Re: JDBC changes for 7.2... some questions...]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (For those unfamiliar with the topic, looking for a way to get the last inserted OID through a sql call, rather than a method call off the JDBC driver) On 23-Aug-2001 Barry Lind wrote: > I would only agree to this functionality if it where a backend function. For me, the best method to deal with this problem is implement the returning clause on the backend... but isn't an option in the short term > 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 This is a problem, I agree. In short, supporting 'select @@last_oid' (my original syntax) is not a framework within itself, but a short-term "kludge" as you mentioned. But what are the options that should be pursued? I want to solve this one way or another. (And willing to work on an acceptable solution.) > 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). Well, it's not really that isolated. The method call 'getLastOID()' isn't in the backend either. That's the problem. This method provides functionality which is very useful, but not in a uniformally applied way where each driver can benefit either. > If the function was implemented in the backend, I think it would be a > good idea. Perhaps this is the solution after all. (And the reason I forward this to the pghackers list as well) Should the backend support the function getLastInsertedOID() or even getLastInsertedPrimaryKey() (or both)? Now, I can try to write the functions, and see if it can be separated into the contrib section of the psql repository if people would like. Does this work for you? (And anyone else reading this) 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 iD8DBQE7hUCLiysnOdCML0URArdAAJ4kI4S00AVzGgazsGS5nTMu+0X8CwCeOLQ8 TVTTzaQdEt6uJrbVAm0Dd4s= =U3aZ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[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 (
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
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? Dave -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: August 23, 2001 10:46 AM To: Peter T Mount Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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? 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] 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? 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] jdbc "proxy" server ...
Quoting "Marc G. Fournier" <[EMAIL PROTECTED]>: > > 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 ... Marc, in the past I used sucessfully the proxygw tool from the fwtk toolkit. Although it wasn't that secure (pg_hba.conf was effectively useless as it saw just the firewall ip), it worked. 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
