Re: [JDBC] jdbc proxy server ...

2001-08-23 Thread Gunnar Rønning

* 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

2001-08-23 Thread Bruce Momjian

 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

2001-08-23 Thread Peter T Mount

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

2001-08-23 Thread Bruce Momjian

 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...

2001-08-23 Thread Barry Lind

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

2001-08-23 Thread Rene Pijlman

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

2001-08-23 Thread Rene Pijlman

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.

2001-08-23 Thread Ned Wolpert

-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]