Re: PostgreSQL General Digest V1 #764 - Mailing list 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--