[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>]
>  Re: Alternate locations of DB's          [Larry Rosenman <[EMAIL PROTECTED]>]
>  Re: Postgres 7.0.2-2 on Red Hat 7.0?    [Lamar Owen <[EMAIL PROTECTED]>]
>  SELECT DISTINCT ON... ORDER BY...
>                                   ["Arthur M. Kang" <[EMAIL PROTECTED]>]
>  getBigDecimal() in JDBC driver not yet implemented ?
>                         ["Nikolaus Rumm" <[EMAIL PROTECTED]>]
>
>------------=_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 ([EMAIL PROTECTED] [162.33.245.46])
>       by hub.org (8.10.1/8.11.0) with ESMTP id e9QJmmU82756
>       for <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 15:48:48 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>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 <[EMAIL PROTECTED]>
>Message-Id: <[EMAIL PROTECTED]>
>Subject: Re: 7.0 vs. 7.1  (was: latest version?)
>In-Reply-To: <[EMAIL PROTECTED]> 
>=?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?= <[EMAIL PROTECTED]>
>Date: Thu, 26 Oct 2000 15:48:24 -0400 (EDT)
>CC: The Hermit Hacker <[EMAIL PROTECTED]>,
>   Holger Klawitter <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>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 <[EMAIL PROTECTED]> 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
>  [EMAIL PROTECTED]               |  (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 <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 17:17:15 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>Received: (from ler@localhost)
>       by lerami.lerctr.org (8.11.1/8.11.1/20000901) id e9QLHCM09889
>       for [EMAIL PROTECTED]; Thu, 26 Oct 2000 16:17:12 -0500 (CDT)
>       (envelope-from ler)
>Date: Thu, 26 Oct 2000 16:17:12 -0500
>From: Larry Rosenman <[EMAIL PROTECTED]>
>To: general-help postgresql <[EMAIL PROTECTED]>
>Subject: Re: Alternate locations of DB's
>Message-ID: <[EMAIL PROTECTED]>
>References: <[EMAIL PROTECTED]> 
><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 
>[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> [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" <[EMAIL PROTECTED]>
>> To: "Brian C. Doyle" <[EMAIL PROTECTED]>
>> Cc: "general-help postgresql" <[EMAIL PROTECTED]>
>> 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
>> > [EMAIL PROTECTED]
>> >
>> > >
>> > > 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: [EMAIL PROTECTED]
>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:[EMAIL PROTECTED] [206.74.232.194])
>       by hub.org (8.10.1/8.11.0) with ESMTP id e9QNYiU61951
>       for <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 19:34:44 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>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: <[EMAIL PROTECTED]>
>Date: Thu, 26 Oct 2000 19:34:27 -0400
>From: Lamar Owen <[EMAIL PROTECTED]>
>X-Mailer: Mozilla 4.73 [en] (Win95; U)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Steve Wolfe <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Postgres 7.0.2-2 on Red Hat 7.0?
>References: 
><[EMAIL PROTECTED]><[EMAIL PROTECTED]><007501c03ea9$da355fa0$[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <002601c03ecc$a2d20fe0$[EMAIL PROTECTED]> 
><[EMAIL PROTECTED]> <00de01c03f63$e2f20d40$[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 19:40:49 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>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" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Cc: "Arthur M. Kang" <[EMAIL PROTECTED]>
>Subject: SELECT DISTINCT ON... ORDER BY...
>Date: Thu, 26 Oct 2000 16:41:13 -0700
>Message-ID: <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]> 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.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
><DIV><FONT face=3DArial size=3D2><SPAN class=3D840413823-26102000><FONT=20
>color=3D#008080>Thomas Metz &lt;</FONT><A href=3D"mailto:[EMAIL PROTECTED]"><FON=
>T=20
>color=3D#008080>[EMAIL PROTECTED]</FONT></A><FONT color=3D#008080>&gt; writes:<B=
>R>&gt;=20
>SELECT DISTINCT ON id id, name FROM test ORDER BY name;<BR>&gt; [doesn't wo=
>rk as=20
>expected]</FONT></SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</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.&nbsp; 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.&nbsp; 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>&nbsp;</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.&nbsp; In=
>=20
>Thomas' example:</SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</DIV>
><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26=
>102000>&gt;=20
>Assuming the table TEST as follows:<BR>&gt; ID&nbsp;&nbsp;&nbsp;&nbsp;=20
>NAME<BR>&gt; - -----------------<BR>&gt; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Alex<BR>&gt; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oliver<BR>&gt;=20
>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thomas<BR>&gt; 2&nbsp;&nbsp;&nbsp;&nbsp;&nb=
>sp;=20
>Fenella</SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</DIV>
><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN class=3D840413823-26=
>102000>&gt;=20
>SELECT DISTINCT ON id id, name FROM test;<BR>&gt; produces:<BR>&gt;=20
>ID&nbsp;&nbsp;&nbsp;&nbsp; NAME<BR>&gt; - -----------------<BR>&gt;=20
>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alex<BR>&gt; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
>;=20
>Oliver</SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Thomas<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Oliver<BR>or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Alex<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Fenella<BR>or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>Thomas<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fenella</SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</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.&nbsp=
>; Do=20
>we really have (or want) a statement with<BR>inherently undefined=20
>behavior?</SPAN></FONT></DIV>
><DIV><FONT color=3D#008080></FONT>&nbsp;</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).&nbsp; 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.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
><DIV><FONT face=3DArial color=3D#008080 size=3D2><SPAN=20
>class=3D840413823-26102000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
>sp;&nbsp;&nbsp;=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 <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 19:42:10 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>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 <[EMAIL PROTECTED]>; Thu, 26 Oct 2000 17:33:44 -0400 (EDT)
>       (envelope-from [EMAIL PROTECTED])
>Received: (from news@localhost)
>       by news.tht.net (8.9.3/8.9.3) id RAA52649
>       for [EMAIL PROTECTED]; 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" <[EMAIL PROTECTED]>
>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$[EMAIL PROTECTED]>
>Date: Thu, 26 Oct 2000 21:19:40 GMT
>X-Complaints-To: [EMAIL PROTECTED]
>X-Trace: news.chello.at 972595180 212.17.86.91 (Thu, 26 Oct 2000 23:19:40 MET DST)
>Organization: Customers chello Austria
>To: [EMAIL PROTECTED]
>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--

Reply via email to