pgsql-general-owner(at)hub(dot)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(at)candle(dot)pha(dot)pa(dot)us>]
> Re: Alternate locations of DB's [Larry Rosenman <ler(at)lerctr(dot)org>]
> Re: Postgres 7.0.2-2 on Red Hat 7.0? [Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>]
> SELECT DISTINCT ON... ORDER BY...
> ["Arthur M. Kang" <arthur(at)levelogic(dot)com>]
> getBigDecimal() in JDBC driver not yet implemented ?
> ["Nikolaus Rumm" <no_spam(dot)nikolaus(dot)rumm(at)chello(dot)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(at)nav-43(dot)dsl(dot)navpoint(dot)com [162.33.245.46])
> by hub.org (8.10.1/8.11.0) with ESMTP id e9QJmmU82756
> for <pgsql-general(at)postgresql(dot)org>; Thu, 26 Oct 2000 15:48:48 -0400 (EDT)
> (envelope-from pgman(at)candle(dot)pha(dot)pa(dot)us)
>Received: (from pgman(at)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(at)candle(dot)pha(dot)pa(dot)us>
>Message-Id: <200010261948(dot)PAA01310(at)candle(dot)pha(dot)pa(dot)us>
>Subject: Re: 7.0 vs. 7.1 (was: latest version?)
>In-Reply-To: <xuyhf5zof9r(dot)fsf(at)hoser(dot)devel(dot)redhat(dot)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(at)redhat(dot)com>
>Date: Thu, 26 Oct 2000 15:48:24 -0400 (EDT)
>CC: The Hermit Hacker <scrappy(at)hub(dot)org>,
> Holger Klawitter <holger(at)klawitter(dot)de>, pgsql-general(at)postgresql(dot)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(at)hub(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org>; Thu, 26 Oct 2000 17:17:15 -0400 (EDT)
> (envelope-from ler(at)lerctr(dot)org)
>Received: (from ler(at)localhost)
> by lerami.lerctr.org (8.11.1/8.11.1/20000901) id e9QLHCM09889
> for pgsql-general(at)postgresql(dot)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(at)lerctr(dot)org>
>To: general-help postgresql <pgsql-general(at)postgresql(dot)org>
>Subject: Re: Alternate locations of DB's
>Message-ID: <20001026161712(dot)A9839(at)lerami(dot)lerctr(dot)org>
>References: <200010261416(dot)JAA11632(at)truck(dot)network(dot)com> <007f01c03f7c$71771ca0$330a0a0a(at)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(at)6014cwpza006>; from aalang(at)rutgersinsurance(dot)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(at)rutgersinsurance(dot)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(at)anubis(dot)network(dot)com>
>> To: "Brian C. Doyle" <brian(at)jbbent(dot)com>
>> Cc: "general-help postgresql" <pgsql-general(at)postgresql(dot)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(at)network(dot)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(at)lerctr(dot)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(at)www(dot)wgcr(dot)org [206.74.232.194])
> by hub.org (8.10.1/8.11.0) with ESMTP id e9QNYiU61951
> for <pgsql-general(at)postgresql(dot)org>; Thu, 26 Oct 2000 19:34:44 -0400 (EDT)
> (envelope-from lamar(dot)owen(at)wgcr(dot)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(dot)4F443D86(at)wgcr(dot)org>
>Date: Thu, 26 Oct 2000 19:34:27 -0400
>From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
>X-Mailer: Mozilla 4.73 [en] (Win95; U)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Steve Wolfe <steve(at)iboats(dot)com>
>CC: pgsql-general(at)postgresql(dot)org
>Subject: Re: Postgres 7.0.2-2 on Red Hat 7.0?
>References: <Pine(dot)BSO(dot)4(dot)10(dot)10010240042560(dot)22422-100000(at)spider(dot)pilosoft(dot)com><39F595F9(dot)36D88BC0(at)wgcr(dot)org><007501c03ea9$da355fa0$50824e40(at)iboats(dot)com> <xuyu2a0y5pl(dot)fsf(at)hoser(dot)devel(dot)redhat(dot)com> <002601c03ecc$a2d20fe0$50824e40(at)iboats(dot)com> <39F79044(dot)BDE8EB0F(at)wgcr(dot)org> <00de01c03f63$e2f20d40$50824e40(at)iboats(dot)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(at)postgresql(dot)org>; Thu, 26 Oct 2000 19:40:49 -0400 (EDT)
> (envelope-from arthur(at)levelogic(dot)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(at)levelogic(dot)com>
>To: <pgsql-general(at)postgresql(dot)org>
>Cc: "Arthur M. Kang" <arthur(at)levelogic(dot)com>
>Subject: SELECT DISTINCT ON... ORDER BY...
>Date: Thu, 26 Oct 2000 16:41:13 -0700
>Message-ID: <NDBBJOJLLCCDNFFLDPPNGEDICAAA(dot)arthur(at)levelogic(dot)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(at)gsf(dot)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(at)gsf(dot)de"><FON=
>T=20
>color=3D#008080>tmetz(at)gsf(dot)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(at)hub(dot)org>; Thu, 26 Oct 2000 19:42:10 -0400 (EDT)
> (envelope-from pgsql-general-owner(at)hub(dot)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(at)postgresql(dot)org>; Thu, 26 Oct 2000 17:33:44 -0400 (EDT)
> (envelope-from news(at)news(dot)tht(dot)net)
>Received: (from news(at)localhost)
> by news.tht.net (8.9.3/8.9.3) id RAA52649
> for pgsql-general(at)postgresql(dot)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(dot)nikolaus(dot)rumm(at)chello(dot)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(dot)66420$mL4(dot)3912703(at)news(dot)chello(dot)at>
>Date: Thu, 26 Oct 2000 21:19:40 GMT
>X-Complaints-To: abuse(at)news(dot)chello(dot)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(at)postgresql(dot)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--