Re: PostgreSQL General Digest V1 #764
От | David C Mudie |
---|---|
Тема | Re: PostgreSQL General Digest V1 #764 |
Дата | |
Msg-id | 200010270045.RAA90144@digitaldeck.com обсуждение исходный текст |
Список | pgsql-general |
pgsql-general-owner@hub.org writes: >This is a multi-part message in MIME format... > >------------=_972603822-62422-5 >Content-Type: text/plain >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: Index >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >PostgreSQL General Digest (mime) - Volume 1 : Issue 764 > >Today's Topics: > Re: 7.0 vs. 7.1 (was: latest version?) > [Bruce Momjian <pgman@candle.pha.pa.us>] > Re: Alternate locations of DB's [Larry Rosenman <ler@lerctr.org>] > Re: Postgres 7.0.2-2 on Red Hat 7.0? [Lamar Owen <lamar.owen@wgcr.org>] > SELECT DISTINCT ON... ORDER BY... > ["Arthur M. Kang" <arthur@levelogic.com>] > getBigDecimal() in JDBC driver not yet implemented ? > ["Nikolaus Rumm" <no_spam.nikolaus.rumm@chello.at>] > >------------=_972603822-62422-5 >Content-Type: multipart/digest; boundary="----------=_972603822-62422-6" >Content-Transfer-Encoding: binary >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >This is a multi-part message in MIME format... > >------------=_972603822-62422-6 >Content-Type: message/rfc822 >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: 200010/1089 >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >Received: from candle.pha.pa.us (pgman@nav-43.dsl.navpoint.com [162.33.245.46]) > by hub.org (8.10.1/8.11.0) with ESMTP id e9QJmmU82756 > for <pgsql-general@postgresql.org>; Thu, 26 Oct 2000 15:48:48 -0400 (EDT) > (envelope-from pgman@candle.pha.pa.us) >Received: (from pgman@localhost) > by candle.pha.pa.us (8.9.0/8.9.0) id PAA01310; > Thu, 26 Oct 2000 15:48:24 -0400 (EDT) >From: Bruce Momjian <pgman@candle.pha.pa.us> >Message-Id: <200010261948.PAA01310@candle.pha.pa.us> >Subject: Re: 7.0 vs. 7.1 (was: latest version?) >In-Reply-To: <xuyhf5zof9r.fsf@hoser.devel.redhat.com> =?ISO-8859-1?Q?from_Trond_Eivind_Glomsr=F8d_at_Oct_26=2C_2000_10=3A20=3A32_a?= > =?ISO-8859-1?Q?m?= >To: =?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <teg@redhat.com> >Date: Thu, 26 Oct 2000 15:48:24 -0400 (EDT) >CC: The Hermit Hacker <scrappy@hub.org>, > Holger Klawitter <holger@klawitter.de>, pgsql-general@postgresql.org >X-Mailer: ELM [version 2.4ME+ PL77 (25)] >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Type: text/plain; charset=US-ASCII >X-Archive-Number: 200010/1089 >X-Sequence-Number: 6927 > >[ Charset ISO-8859-1 unsupported, converting... ] >> The Hermit Hacker <scrappy@hub.org> writes: >> >> > On Wed, 25 Oct 2000, Holger Klawitter wrote: >> > >> > > Pawel Wegrzyn wrote: >> > > > >> > > > Hi, >> > > > What is the latest version of PostgreSQL? >> > > > Is there something like 7.1? >> > > >> > > The most recent version 7.0.2. 7.1 is about to come - I am looking >> > > forward to it as well. >> > >> > 7.0.3 is about to come out, 7.1 is about 2 months away yet :) >> >> How compatible with 7.0 and 7.1 be from an application standpoint? >> Will applications linked with libraries from 7.0 be able to talk to >> the 7.1 database? Any changes in library major versions? The other >> way? > >Historically, all applications have been able to talk to newer servers, >so a 6.4 client can talk to a 7.0 postmaster, and I believe 7.0 clients >can talk to 7.1 postmasters. > >We usually do not go the other way, where 6.5 clients can not talk to >6.4 postmasters. I believe 7.0->7.1 will be able to talk in any >7.0.X/7.1 client and server combination. > >-- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > >------------=_972603822-62422-6 >Content-Type: message/rfc822 >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: 200010/1090 >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11]) > by hub.org (8.10.1/8.11.0) with ESMTP id e9QLHEU39688 > for <pgsql-general@postgresql.org>; Thu, 26 Oct 2000 17:17:15 -0400 (EDT) > (envelope-from ler@lerctr.org) >Received: (from ler@localhost) > by lerami.lerctr.org (8.11.1/8.11.1/20000901) id e9QLHCM09889 > for pgsql-general@postgresql.org; Thu, 26 Oct 2000 16:17:12 -0500 (CDT) > (envelope-from ler) >Date: Thu, 26 Oct 2000 16:17:12 -0500 >From: Larry Rosenman <ler@lerctr.org> >To: general-help postgresql <pgsql-general@postgresql.org> >Subject: Re: Alternate locations of DB's >Message-ID: <20001026161712.A9839@lerami.lerctr.org> >References: <200010261416.JAA11632@truck.network.com> <007f01c03f7c$71771ca0$330a0a0a@6014cwpza006> >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >User-Agent: Mutt/1.3.10i >In-Reply-To: <007f01c03f7c$71771ca0$330a0a0a@6014cwpza006>; from aalang@rutgersinsurance.com on Thu, Oct 26, 2000 at 02:41:27PM-0400 >X-Mailer: Mutt http://www.mutt.org/ >X-Archive-Number: 200010/1090 >X-Sequence-Number: 6928 > >What's wrong with: > >pg_ctl -D /some/place/number1 -o "-p 5432 -i" >pg_ctl -D /some/place/number2 -o "-p 5433 -i" >pg_ctl -D /some/other/place -o "-p 6432 -i" > >Larry >* Adam Lang <aalang@rutgersinsurance.com> [001026 14:33]: >> But I think he wants to know how to have 3 different databases in three >> different locations. >> >> Adam Lang >> Systems Engineer >> Rutgers Casualty Insurance Company >> ----- Original Message ----- >> From: "Wade D. Oberpriller" <oberpwd@anubis.network.com> >> To: "Brian C. Doyle" <brian@jbbent.com> >> Cc: "general-help postgresql" <pgsql-general@postgresql.org> >> Sent: Thursday, October 26, 2000 10:16 AM >> Subject: Re: [GENERAL] Alternate locations of DB's >> >> >> > You must use initlocation to initialize the location and have the path to >> the >> > location in an environment variable before postmaster is started. >> > >> > For example: >> > >> > > setenv PGDATA2 /home/someuser/data >> > > initlocation 'PGDATA2' >> > > pg_ctl -D /home/pgsql/data start >> > > createdb mydb -D 'PGDATA2' >> > >> > This will start postmaster with the knowlegde of the PGDATA2 environment >> > variable. Then you can create databases in this alternate location. >> > PostgreSQL can also be compiled with an option to allow absolute paths, so >> > >> > >createdb cdt -D /home/someuser/data >> > >> > can be done, but I forget the option. The user's manual describes all of >> this >> > under CREATEDB. >> > >> > Wade Oberpriller >> > StorageTek >> > oberpwd@network.com >> > >> > > >> > > Hello all, >> > > >> > > How do I get Postgresql to use independantly seperate db >> > > locations. Currently I have them under /home/user/database and as long >> as >> > > i get postmaster to run with that same location I am fine but I want to >> have >> > > /home/user/database >> > > /home/user1/database >> > > /home/userr2/database >> > > ect... >> > > >> > > But I can only get one instance of the postmaster running at a time . >> How >> > > do i change that if i can! >> > > >> > > >> > > > >-- >Larry Rosenman http://www.lerctr.org/~ler >Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org >US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > >------------=_972603822-62422-6 >Content-Type: message/rfc822 >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: 200010/1091 >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194]) > by hub.org (8.10.1/8.11.0) with ESMTP id e9QNYiU61951 > for <pgsql-general@postgresql.org>; Thu, 26 Oct 2000 19:34:44 -0400 (EDT) > (envelope-from lamar.owen@wgcr.org) >Received: from wgcr.org ([206.74.232.204]) > by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id TAA26127; > Thu, 26 Oct 2000 19:34:38 -0400 >Message-ID: <39F8BF83.4F443D86@wgcr.org> >Date: Thu, 26 Oct 2000 19:34:27 -0400 >From: Lamar Owen <lamar.owen@wgcr.org> >X-Mailer: Mozilla 4.73 [en] (Win95; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: Steve Wolfe <steve@iboats.com> >CC: pgsql-general@postgresql.org >Subject: Re: Postgres 7.0.2-2 on Red Hat 7.0? >References: <Pine.BSO.4.10.10010240042560.22422-100000@spider.pilosoft.com><39F595F9.36D88BC0@wgcr.org><007501c03ea9$da355fa0$50824e40@iboats.com> <xuyu2a0y5pl.fsf@hoser.devel.redhat.com><002601c03ecc$a2d20fe0$50824e40@iboats.com> <39F79044.BDE8EB0F@wgcr.org> <00de01c03f63$e2f20d40$50824e40@iboats.com> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit >X-Archive-Number: 200010/1091 >X-Sequence-Number: 6929 > >Steve Wolfe wrote: >> > Then upgrade the RPM's. It isn't hard. > >> OK, here's a situation. One of the programmers at your company runs the >> disk out of space. You're going to go bonk him on the head, but first, >> there are more pressing matters. PostgreSQL 6.5 has horked up the tables, >> and needs to be fixed. 7.0 is released, which has a fix for the problem. > >Not a good example, but I understand your comparison. > >> Are you going to sit around waiting for RPM's, while your tables are all >> horked up, and the programming department is breathing down your neck >> because they can't get work done? > >Actually, since I'm the RPM maintainer, I'll build a set for the new >version (which I would have been tracking since the first beta) the hour >it is released. That is if I'm online when the release occurs. But, >then again, I'll have already built RPM's for the beta releases. > >It's this very problem that got me in this business of maintaining the >RPM's in the first place over a year ago. Scratch that itch..... > >> > If you're going to install from source on a RedHat machine, it is simply >> > prudent practice, regardless of the package, to make sure the RPM >> > version is not already installed. >> >> I agree. >> >> > And, the fact of the matter is that there are likely far more PostgreSQL >> > installations from RPM than from source. >> >> I fail to see the relevance of that argument. Popularity does not make >> correctness. If I'm just being extremely dense about that sentence, feel >> free to let me know. > >The relevance is that most who use it don't really care where the stuff >is. They just want to upgrade. >-- >Lamar Owen >WGCR Internet Radio >1 Peter 4:11 > >------------=_972603822-62422-6 >Content-Type: message/rfc822 >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: 200010/1092 >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >Received: from ultra.levelogic.com (ultra.levelogic.com [209.75.61.10]) > by hub.org (8.10.1/8.11.0) with ESMTP id e9QNenU66741 > for <pgsql-general@postgresql.org>; Thu, 26 Oct 2000 19:40:49 -0400 (EDT) > (envelope-from arthur@levelogic.com) >Received: from arthur (arthur.levelogic.com [209.75.61.100]) > by ultra.levelogic.com (8.9.1a/8.9.1) with SMTP id QAA10745; > Thu, 26 Oct 2000 16:34:32 -0700 (PDT) >From: "Arthur M. Kang" <arthur@levelogic.com> >To: <pgsql-general@postgresql.org> >Cc: "Arthur M. Kang" <arthur@levelogic.com> >Subject: SELECT DISTINCT ON... ORDER BY... >Date: Thu, 26 Oct 2000 16:41:13 -0700 >Message-ID: <NDBBJOJLLCCDNFFLDPPNGEDICAAA.arthur@levelogic.com> >MIME-Version: 1.0 >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0007_01C03F6B.8DD263C0" >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 >Importance: Normal >X-Archive-Number: 200010/1092 >X-Sequence-Number: 6930 > >This is a multi-part message in MIME format. > >------=_NextPart_000_0007_01C03F6B.8DD263C0 >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: 7bit > >Did massive amounts of searching and read Tom Lane's post regarding the >subject, but that was dated January of 1999. Was wondering if anyone know >if there was any progress on the issue and what the resulting outcome was. > >Is there a way to select distinct on one column and sort by another? > >Any help is appreciated... > >Arthur > >Thomas Metz <tmetz@gsf.de> writes: >> SELECT DISTINCT ON id id, name FROM test ORDER BY name; >> [doesn't work as expected] > >There have been related discussions before on pg-hackers mail list; >you might care to check the list archives. The conclusion I recall >is that it's not real clear how the combination of SELECT DISTINCT >on one column and ORDER BY on another *should* work. Postgres' >current behavior is clearly wrong IMHO, but there isn't a unique >definition of right behavior, because it's not clear which tuples >should get selected for the sort. > >This "SELECT DISTINCT ON attribute" option strikes me as even more >bogus. Where did we get that from --- is it in the SQL92 standard? >If you SELECT DISTINCT on a subset of the attributes to be returned, >then there's no unique definition of which values get returned in the >other columns. In Thomas' example: > >> Assuming the table TEST as follows: >> ID NAME >> - ----------------- >> 1 Alex >> 2 Oliver >> 1 Thomas >> 2 Fenella > >> SELECT DISTINCT ON id id, name FROM test; >> produces: >> ID NAME >> - ----------------- >> 1 Alex >> 2 Oliver > >There's no justifiable reason for preferring this output over > 1 Thomas > 2 Oliver >or > 1 Alex > 2 Fenella >or > 1 Thomas > 2 Fenella > >Any of these are "DISTINCT ON id", but it's purely a matter of >happenstance table order and unspecified implementation choices which >one will appear. Do we really have (or want) a statement with >inherently undefined behavior? > >Anyway, to answer Thomas' question, the way SELECT DISTINCT is >implemented is that first there's a sort on the DISTINCT columns, >then there's a pass that eliminates adjacent duplicates (like the Unix >uniq(1) program). In the current backend, doing an ORDER BY on another >column overrides the sorting on the DISTINCT columns, so when the >duplicate-eliminator runs it will fail to get rid of duplicates that >don't happen to appear consecutively in its input. That's pretty >broken, but then the entire concept of combining these two options >doesn't seem well defined; the SELECT DISTINCT doesn't make any promises >about which tuples (with the same DISTINCT columns) it's going to pick, >therefore the result of ordering by some other column isn't clear. > >If you're willing to live with poorly defined behavior, the fix >is fairly obvious: run the sort and uniq passes for the DISTINCT >columns, *then* run the sort on the ORDER BY columns --- which >will use whichever tuple the DISTINCT phase selected at random >out of each set with the same DISTINCT value. > >I think the issue got put on the back burner last time in hopes that >some definition with consistent behavior would come up, but I haven't >seen any hope that there is one. > > regards, tom lane > >------=_NextPart_000_0007_01C03F6B.8DD263C0 >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ><HTML><HEAD> ><META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-125= >2"> ><META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR></HEAD> ><BODY> ><DIV><FONT face=3DArial size=3D2><SPAN class=3D840413823-26102000>Did massi= >ve amounts=20 >of searching and read Tom Lane's post regarding the subject, but that was d= >ated=20 >January of 1999. Was wondering if anyone know if there was any progre= >ss on=20 >the issue and what the resulting outcome was.</SPAN></FONT></DIV> ><DIV><FONT face=3DArial size=3D2><SPAN=20 >class=3D840413823-26102000></SPAN></FONT> </DIV> ><DIV><FONT face=3DArial size=3D2><SPAN class=3D840413823-26102000>Is there = >a way to=20 >select distinct on one column and sort by another?</SPAN></FONT></DIV> ><DIV><FONT face=3DArial size=3D2><SPAN=20 >class=3D840413823-26102000></SPAN></FONT> </DIV> ><DIV><FONT face=3DArial size=3D2><SPAN class=3D840413823-26102000>Any help = >is=20 >appreciated...</SPAN></FONT></DIV> ><DIV><FONT face=3DArial size=3D2><SPAN=20 >class=3D840413823-26102000></SPAN></FONT> </DIV> ><DIV><FONT face=3DArial size=3D2><SPAN=20 >class=3D840413823-26102000>Arthur</SPAN></FONT></DIV> ><DIV><FONT face=3DArial size=3D2><SPAN=20 >class=3D840413823-26102000></SPAN></FONT> </DIV> ><DIV><FONT face=3DArial size=3D2><SPAN class=3D840413823-26102000><FONT=20 >color=3D#008080>Thomas Metz <</FONT><A href=3D"mailto:tmetz@gsf.de"><FON= >T=20 >color=3D#008080>tmetz@gsf.de</FONT></A><FONT color=3D#008080>> writes:<B= >R>>=20 >SELECT DISTINCT ON id id, name FROM test ORDER BY name;<BR>> [doesn't wo= >rk as=20 >expected]</FONT></SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>There=20 >have been related discussions before on pg-hackers mail list;<BR>you might = >care=20 >to check the list archives. The conclusion I recall<BR>is that it's n= >ot=20 >real clear how the combination of SELECT DISTINCT<BR>on one column and ORDE= >R BY=20 >on another *should* work. Postgres'<BR>current behavior is clearly wr= >ong=20 >IMHO, but there isn't a unique<BR>definition of right behavior, because it'= >s not=20 >clear which tuples<BR>should get selected for the sort.</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>This=20 >"SELECT DISTINCT ON attribute" option strikes me as even more<BR>bogus.&nbs= >p;=20 >Where did we get that from --- is it in the SQL92 standard?<BR>If you SELEC= >T=20 >DISTINCT on a subset of the attributes to be returned,<BR>then there's no u= >nique=20 >definition of which values get returned in the<BR>other columns. In= >=20 >Thomas' example:</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>>=20 >Assuming the table TEST as follows:<BR>> ID =20 >NAME<BR>> - -----------------<BR>> 1 =20 >Alex<BR>> 2 Oliver<BR>>=20 >1 Thomas<BR>> 2 &nb= >sp;=20 >Fenella</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>>=20 >SELECT DISTINCT ON id id, name FROM test;<BR>> produces:<BR>>=20 >ID NAME<BR>> - -----------------<BR>>=20 >1 Alex<BR>> 2  = >;=20 >Oliver</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN=20 >class=3D840413823-26102000>There's no justifiable reason for preferring thi= >s=20 >output over<BR> =20 >1 =20 >Thomas<BR> =20 >2 =20 >Oliver<BR>or<BR> =20 >1 =20 >Alex<BR> =20 >2 =20 >Fenella<BR>or<BR> =20 >1 =20 >Thomas<BR> =20 >2 Fenella</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>Any of=20 >these are "DISTINCT ON id", but it's purely a matter of<BR>happenstance tab= >le=20 >order and unspecified implementation choices which<BR>one will appear. = >; Do=20 >we really have (or want) a statement with<BR>inherently undefined=20 >behavior?</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN=20 >class=3D840413823-26102000>Anyway, to answer Thomas' question, the way SELE= >CT=20 >DISTINCT is<BR>implemented is that first there's a sort on the DISTINCT=20 >columns,<BR>then there's a pass that eliminates adjacent duplicates (like t= >he=20 >Unix<BR>uniq(1) program). In the current backend, doing an ORDER BY o= >n=20 >another<BR>column overrides the sorting on the DISTINCT columns, so when=20 >the<BR>duplicate-eliminator runs it will fail to get rid of duplicates=20 >that<BR>don't happen to appear consecutively in its input. That's=20 >pretty<BR>broken, but then the entire concept of combining these two=20 >options<BR>doesn't seem well defined; the SELECT DISTINCT doesn't make any= >=20 >promises<BR>about which tuples (with the same DISTINCT columns) it's going = >to=20 >pick,<BR>therefore the result of ordering by some other column isn't=20 >clear.</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>If=20 >you're willing to live with poorly defined behavior, the fix<BR>is fairly= >=20 >obvious: run the sort and uniq passes for the DISTINCT<BR>columns, *then* r= >un=20 >the sort on the ORDER BY columns --- which<BR>will use whichever tuple the= >=20 >DISTINCT phase selected at random<BR>out of each set with the same DISTINCT= >=20 >value.</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26= >102000>I=20 >think the issue got put on the back burner last time in hopes that<BR>some= >=20 >definition with consistent behavior would come up, but I haven't<BR>seen an= >y=20 >hope that there is one.</SPAN></FONT></DIV> ><DIV><FONT color=3D#008080></FONT> </DIV> ><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN=20 >class=3D840413823-26102000> = > &nb= >sp; =20 >regards, tom lane</SPAN></FONT></DIV></BODY></HTML> > >------=_NextPart_000_0007_01C03F6B.8DD263C0-- > > >------------=_972603822-62422-6 >Content-Type: message/rfc822 >Content-Disposition: inline >Content-Transfer-Encoding: binary >Content-Description: 200010/1093 >Mime-Version: 1.0 >X-Mailer: MIME-tools 5.316 (Entity 5.212) > >Received: from hub.org.org (localhost [127.0.0.1]) > by hub.org (8.10.1/8.11.0) with SMTP id e9QNg9U67750 > for <pgsql-general@hub.org>; Thu, 26 Oct 2000 19:42:10 -0400 (EDT) > (envelope-from pgsql-general-owner@hub.org) >Received: from news.tht.net (news.hub.org [216.126.91.242]) > by hub.org (8.10.1/8.11.0) with ESMTP id e9QLXeU69811 > for <pgsql-general@postgresql.org>; Thu, 26 Oct 2000 17:33:44 -0400 (EDT) > (envelope-from news@news.tht.net) >Received: (from news@localhost) > by news.tht.net (8.9.3/8.9.3) id RAA52649 > for pgsql-general@postgresql.org; Thu, 26 Oct 2000 17:19:43 -0400 (EDT) > (envelope-from news) >X-Authentication-Warning: news.tht.net: news set sender to <news> using -f >From: "Nikolaus Rumm" <no_spam.nikolaus.rumm@chello.at> >X-Newsgroups: comp.databases.postgresql.questions >Subject: getBigDecimal() in JDBC driver not yet implemented ? >Lines: 15 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 >Message-ID: <Md1K5.66420$mL4.3912703@news.chello.at> >Date: Thu, 26 Oct 2000 21:19:40 GMT >X-Complaints-To: abuse@news.chello.at >X-Trace: news.chello.at 972595180 212.17.86.91 (Thu, 26 Oct 2000 23:19:40 MET DST) >Organization: Customers chello Austria >To: pgsql-general@postgresql.org >X-Archive-Number: 200010/1093 >X-Sequence-Number: 6931 >MIME-Version: 1.0 > >Hello, > >upon making a call to ResultSet.getBigDecimal(String column_name) I get an >SQLException with the following message: >This method is not yet implemented. > >Can this be ? getBigDecimal() is vital to most JDBC applications because it >is widely used as the primary key datatype. >I use the JDBC driver <jdbc7.0-1.2>. > >Any suggestions ? > >Nikolaus Rumm > > > >------------=_972603822-62422-6-- > >------------=_972603822-62422-5--
В списке pgsql-general по дате отправления: