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.


Ned Wolpert wrote:
> 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.
>>Ned Wolpert wrote:
>>>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
>>>Could we just do 
>>>'select getInsertedOID()'
>>>which would break people who have functions called getInsertedOID() of
>>>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?
>>>Ned Wolpert <[EMAIL PROTECTED]>
>>>D08C2F45:  28E7 56CB 58AC C622 5A51  3C42 8B2B 2739 D08C 2F45 
>>>Version: GnuPG v1.0.6 (GNU/Linux)
>>>Comment: For info see
>>>-----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 
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see
> iD8DBQE7g+agiysnOdCML0URAvbvAJ9GO/spmwQYZessjk4IenhtPuguSwCdHRQN
> xH+tnGqKpmg/UOSnxOevek0=
> =pcr+
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to