Re: JDBC changes for 7.2... some questions... - Mailing list pgsql-jdbc

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 <ned.wolpert@knowledgenet.com> 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 <ned.wolpert@knowledgenet.com>
>>>
>>>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 majordomo@postgresql.org)
>>>
>>>
>>>
>
>
> Virtually,
> Ned Wolpert <ned.wolpert@knowledgenet.com>
>
> 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 broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
>