Skip site navigation (1) Skip section navigation (2)

Re: Re: JDBC changes for 7.2... some questions...

From: Peter Wiley <wiley(at)mmspl(dot)com(dot)au>
To: Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)com>
Cc: Barry Lind <barry(at)xythos(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: JDBC changes for 7.2... some questions...
Date: 2001-08-22 22:33:28
Message-ID: Pine.LNX.4.33.0108230830420.2122-100000@rex.vpn.mmsi.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
>
> What's your thoughts?  Do you see the need for the functionality?  Do you have
> a solution that I need?

Definitely need the functionality. It's one of the things holding up me
porting an Informix system. Laziness is a bigger holdup of course - the
Informix system is so bulletproof and I'm slowly re-writing all the 4GL in
Java.

FWIW, Informix returns the new SERIAL value through a structure
SQLCA.SQLERRD[3] from memory. Not applicable to a PostgreSQL solution I'd
say.

>
> 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(dot)wolpert(at)knowledgenet(dot)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(dot)wolpert(at)knowledgenet(dot)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(at)postgresql(dot)org)
> >>
> >>
>
>
> Virtually,
> Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)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
>


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-08-22 23:04:06
Subject: Re: Patch list delay
Previous:From: Peter EisentrautDate: 2001-08-22 22:18:32
Subject: Assessment on namespace clean include file names

pgsql-jdbc by date

Next:From: Bruce MomjianDate: 2001-08-22 23:05:07
Subject: Re: Re: JDBC changes for 7.2... some questions...
Previous:From: Alejandro Aguilar SierraDate: 2001-08-22 22:12:09
Subject: Latin1 characters

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group