Re: [GENERAL] +/- Inf for float8's

So, any suggestions as to how we can store +/- infinity as a valid float8
value in a database table?

Right: the SQL standard doesn't say anything about what to do for these
cases for floats (except by defining the syntax of an approximate numeric
constant as basically a float), but the IEEE754 does: as you discovered
below, they're NaN, -Infinity, and +Infinity.

Not all computers fully support IEEE754, though many new ones do.

I notice, btw, that 'NaN' is accepted as a valid float8. Is there any
particular reason why something similar for, eg '-Inf' and 'Inf' doesn't
also exist? Just discovered, there is a special number 'Infinity', which
seems to be recognised, except you can't insert it into a table because it
reports an overflow error. Getting warm, it seems, but not there yet. And
there doesn't seem to be a negative equivalent.

And this is a bug. From looking at the source, I see that Thomas added
code to accept 'NaN' and 'Infinity' (but not '-Infinity'), and Tom Lane
tweaked it, but it's never been able to get an Infinity all the way to
the table, as far as I can see: the value gets set to HUGE_VAL, but the
call to CheckFloat8Val compares against FLOAT8_MAX (and FLOAT8_MIN),
and complains, since HUGE_VAL is _defined_ to be larger than DBL_MAX.
And, there's no test case in the regression tests for inserting NaN or
Infinity. (Shame on Thomas ;-)

Ah, I'm just trying to leave some rewarding work for other folks ;)

I think the right thing to do is move the call to CheckFloat8Val into a
branch of the test for NaN and Infinity, thereby not calling it if we've
been passed those constants. I'm compiling up a test of this right now,
and I'll submit a patch to Bruce if it passes regression. Looks like
that function hasn't been touch in a while, so the patch should apply
to 7.0.X as well as current CVS.

istm that the existing protection (or something like it) is required for
some platforms, while other platforms may be able to handle NaN and
+/-Inf just fine. Seems like a job for autoconf to determine the FP
capabilities of a system, unless Posix defines some way to tell. Of
course, even then we'd need an autoconf test to deal with non-Posix
platforms.

Looks like it works, and passes the regression tests as they are. I'm
patching the tests to include the cases 'NaN', 'Infinity', and '-Infinity'
as valid float8s, and 'not a float' as an invalid representation, and
rerunning to get output to submit with the patch. This might be a bit
hairy, since there are 5 different expected/float8* files. Should I try
to hand patch them to deal with the new rows, or let them be regenerated
by people with the appropriate platforms?

How about setting up a separate test (say, ieee754.sql) so that
non-compliant platforms can still pass the original FP test suite. Then
other platforms can be added in as they are tested.

Some platforms may need their compiler switches tweaked; I haven't
checked the Alpha/DUnix configuration but I recall needing to fix some
flags to get compiled code to move these edge cases around even just
through subroutine calls. One example was in trying to call finite(),
which threw an error during the call to it if the number was NaN or
Infinity. Which sort of defeated the purpose of the call :)

Bigger problem with changing the float8 regression tests: a lot of our
math functions seem to be guarded with CheckFloat8Val(result), so, if we
allow these values in a float8 column, most of the math functions with
elog(). It strikes me that there must have been a reason for this at one
time. There's even a #define UNSAFE_FLOATS, to disable these checks. By
reading the comments in old copies of float.c, it looks like this was
added for an old, buggy linux/Alpha libc that would throw floating point
exceptions, otherwise.

There are still reasons on some platforms, as noted above...

Is there an intrinsic problem with allowing values outside the range
FLOAT8_MAX <= x =>FLOAT8_MIN ? 'ORDER BY' seems to still work, with
'Infinity' and '-Infinity' sorting properly. Having a 'NaN' in there
breaks sorting however. That's a current, live bug. Could be fixed
by treating 'NaN' as a different flavor of NULL. Probably a fairly deep
change, however. Hmm, NULL in a float8 sorts to the end, regardless of
ASC or DESC, is that right?

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

Anyway, here's the patch for just float.c , if anyone wants to look
at it. As I said, it passes the existing float8 regression tests, but
raises a lot of interesting questions.

Are you interested in pursuing this further? It seems like we might be
able to move in the direction you suggest on *some* platforms, but we
will need to scrub the math functions to be able to handle these edge
cases.

- Thomas

On Tue, Aug 15, 2000 at 03:27:55AM +0000, Thomas Lockhart wrote:

Not all computers fully support IEEE754, though many new ones do.

True - the question becomes: how new is new? Are we supporting ones
that aren't? If so, that's fine. If not, it's a lot easier to fix. ;-)

And, there's no test case in the regression tests for inserting NaN or
Infinity. (Shame on Thomas ;-)

Ah, I'm just trying to leave some rewarding work for other folks ;)

And we appreciate the crumbs. Actually, it _was_ good practice grovelling
out versions from CVS and matching log messages.

istm that the existing protection (or something like it) is required for
some platforms, while other platforms may be able to handle NaN and
+/-Inf just fine. Seems like a job for autoconf to determine the FP
capabilities of a system, unless Posix defines some way to tell. Of
course, even then we'd need an autoconf test to deal with non-Posix
platforms.

Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
and the CheckFloat[48]Val functions just return true.

How about setting up a separate test (say, ieee754.sql) so that
non-compliant platforms can still pass the original FP test suite. Then
other platforms can be added in as they are tested.

Hmm, I wish we had clue what other systems might be non-compliant, and how.
The question becomes one of if it's _possible_ to support NaN, +/-Inf on
some platforms. Then, we end up with a difference in functionality.

Is there an intrinsic problem with allowing values outside the range
FLOAT8_MAX <= x =>FLOAT8_MIN ? 'ORDER BY' seems to still work, with
'Infinity' and '-Infinity' sorting properly. Having a 'NaN' in there
breaks sorting however. That's a current, live bug. Could be fixed
by treating 'NaN' as a different flavor of NULL. Probably a fairly deep
change, however. Hmm, NULL in a float8 sorts to the end, regardless of
ASC or DESC, is that right?

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar. Neither one
can be placed corectly with respect to the other values: NULL, because
we don't know were it really is, NaN because we know it's not even on
this axis. I'm suggesting the we fix sorting on floats to treat NaN as
NULL, and sort it to the end. As it stands, sorting is broken, since it
returns the NaN rows wherever they happen to be. This causes them to
act as barriers, partitioning the returned set into seperately sorted
sub sequences.

Anyway, here's the patch for just float.c , if anyone wants to look
at it. As I said, it passes the existing float8 regression tests, but
raises a lot of interesting questions.

Are you interested in pursuing this further? It seems like we might be
able to move in the direction you suggest on *some* platforms, but we
will need to scrub the math functions to be able to handle these edge
cases.

Sure. I'm no great floating point wiz, but I'm sure Tom and Don will
jump on anything I get wrong. Duping the float tests and feeding them
NaN/+/-Inf as a seperate test set is probably a good idea.

The existing patch moves the call to CheckFloat8Val() inside float8in
so it is only called if strtod() consumes all it's input, and does not
set errno. Seems safe to me: if strtod() doesn't consume it's input,
we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
for those three values), else elog(). If it does, but sets errno,
we catch that. Then, in belt-and-suspenders style, we call
CheckFloat8Val(). For that check to fail, strtod() would have to consume
its entire input, return +/-HUGE_VAL, and _not_ set errno to ERANGE.

BTW, this also brings up something that got discussed before the last
release, but never implemented. The original problem from Tim Allen had
to do with using a work around for not having +/- Inf: storing the values
-1.79769313486232e+308 and 1.79769313486232e+308. He was having trouble,
since a pg_dump/restore cycle broke, do to rounding the values to out
of range for floats. This wasn't caught by the current regression tests,
but would have been caught by the suggested dump/restore/dump/compare
dumps cycle someone suggested for exercizing the *out and *in functions.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

Thomas -
A general design question. There seems to be a good reason to allow +/-Inf
in float8 columns: Tim Allen has an need for them, for example. That's
pretty straight forward, they seem to act properly if the underlying float
libs handle them.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Hmm. With Tom Lane's new fmgr interface, you *can* return NULL if you
spot a NaN result. Maybe that is the best way to go about it; we'll
stipulate that NaN and NULL are equivalent. And we'll further stipulate
that if you are messing with NaN then you deserve what you get ;)

- Thomas

I can't say whether its worth the trouble to add NaN, but I will say that NaN
is not the same as NULL. NULL is missing data; NaN is 0./0. The difference
is significant for numerical applications.

Tim

"Ross J. Reedstrom" wrote:

Thomas -
A general design question. There seems to be a good reason to allow +/-Inf
in float8 columns: Tim Allen has an need for them, for example. That's
pretty straight forward, they seem to act properly if the underlying float
libs handle them.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

--
Timothy H. Keitt
National Center for Ecological Analysis and Synthesis
735 State Street, Suite 300, Santa Barbara, CA 93101
Phone: 805-892-2519, FAX: 805-892-2510
http://www.nceas.ucsb.edu/~keitt/

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Ross

Just a wild guess, NaN could be used to indicated invalid numeric
data. However, this seems odd because it should have been checked prior to
being put in the DB.

NULL is no value, +/- infinity could be just that or out of range, unless
you want NaN to be out of range. Depending on your scheme for
representation you could take an out of range value and store it as +/i
infinity.

These are just suggestions.

Thomas

Hi,

just to add my opinion on NaN in the IEEE standard. As far as I
remember, IEEE numbers work as follows:

1 bit sign
some bits base
some bits exponent

This allows you to do several things:

interpret the exp bits as a normal integer and get
- exp=below half: negative exponents
- exp=half: exponent=0
- exp=above half: positive exponents
- exp=all set: NaN, quite a few at that

For all of these the sign can be either positive or negative, leading
to pos/neg zero (quite a strange concept).

With the NaNs, you get quite a few possibilities, but notably:
- base=0 (NaN -- this is not a number, but an animal)
- base=max (pos/neg infinity, depending on sign)

Someone mentioned a representation for 0/0 and I might add that there
are four possibilities:
(( 1.)*0.) / (( 1.)*0.)
(( 1.)*0.) / ((-1.)*0.)
((-1.)*0.) / (( 1.)*0.)
((-1.)*0.) / ((-1.)*0.)
These (given commutativity, except that we're dealing with a finite
representation, but predictable in that it is actually possible to
factor out the sign) can be reduced to:
( 1) * (0./0.)
(-1) * (0./0.)
which amounts to pos/neg infinity of some sort.

Now my take on NULL vs NaN is that there should be a whole bunch of
NULL, just like there is a whole bunch of NaN. Just off the top of my
head, I could imagine "unknown", "unknowable", "out of range in
direction X". But, alas, the SQL standard doesn't provide for such
things (though the storage implementation would: but what would you do
with comparisons, conversions and displays?).

so long,

Oliver

Thomas -
A general design question. There seems to be a good reason to
allow +/-Inf in float8 columns: Tim Allen has an need for them, for
example. That's pretty straight forward, they seem to act properly if
the underlying float libs handle them.

Thanks for pursuing this, Ross. I shall look forward to not having to use
a workaround in future versions.

I'm not convinced NaN gives us anything useful, especially given how
badly it breaks sorting. I've been digging into that code a little,
and it's not going to be pretty. It strikes me as wrong to embed type
specific info into the generic sorting routines.

Actually, we also have a use for NaN. The main thing we're using this for
is to store "fields", ie general descriptions of particular items of
metadata that occur in our application. Each field can have a validity
condition (ie min <= X <= max), and for open ranges we find the easiest
way to handle that without needing any extra bool flags or whatever is
just to set the minimum value to -infinity and/or the max to +infinity.

Our fields also have a default value, used in case the user didn't
actually enter anything. However, we want to be able to support something
like a NULL, so that if the user doesn't enter anything then in some cases
that means "there is no value". These values get passed around inside our
applications in various ways, in subsystems that don't have any direct
communication with the database, so using a database NULL doesn't do the
job. An NaN, however, is perfect for the job, because you can transmit
NaN's down sockets between processes, you can copy them around without
needing any special handling, and you can (currently) write them to and
read them from the database. So, for what it's worth, here's one vote for
keeping NaN's. As for sorting, we don't really care how they sort. Any
consistent behaviour will do for us.

Yes, there is a difference between an NaN and a NULL, but that difference
is not important in our application. We never do any serious arithmetic on
our float8 values, we just store them in the database and allow users to
view and edit the values.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

It's this last point that makes NaN's useful; most non DB numeric
applications don't have a NULL, and NaN can make an adequate substitute.
One thing we could do, I suppose, is add code to our db interface layer to
translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
happier :-).

Ross

Tim

--
-----------------------------------------------
Tim Allen tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/
http://www4.tpg.com.au/users/rita_tim/

On Wed, Aug 16, 2000 at 11:16:24AM +1000, Tim Allen wrote:

Thanks for pursuing this, Ross. I shall look forward to not having to use
a workaround in future versions.

See, Tim knows how to get work out of Open Source programmers. Flattery, not
flames ;-)

Actually, we also have a use for NaN. The main thing we're using this for

<snip>

read them from the database. So, for what it's worth, here's one vote for
keeping NaN's. As for sorting, we don't really care how they sort. Any
consistent behaviour will do for us.

Right. Currently, NaN's break sorting of everything else in the column.
Not good. But Thomas mentioned a possible clever work around. I've got to
dig into the code a bit more to see if it'll work.

Yes, there is a difference between an NaN and a NULL, but that difference
is not important in our application. We never do any serious arithmetic on
our float8 values, we just store them in the database and allow users to
view and edit the values.

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

It's this last point that makes NaN's useful; most non DB numeric
applications don't have a NULL, and NaN can make an adequate substitute.
One thing we could do, I suppose, is add code to our db interface layer to
translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
happier :-).

Well, this is open source: all we need is one customer, if the idea
is sound. (Usually, that's the coder themselves, but not always. And
conversely, if it's a lousy idea, it doesn't matter howmany people
want it!) I had forgotten that the DB often interacts with non-DB
code. (What, you mean psql and hand typed queries isn't good enough for
your clients?) 'Course, I'm the type that's been known to code figures
directly in Postscript because the drawing package wouldn't do what I
wanted to.

I'll definitely look into this some more. If we can solve the sort
problem without to big a kludge, I think we might be able to let people
do serious math in the backend, let the non-finites fly!

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

Ross J. Reedstrom writes:

Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
and the CheckFloat[48]Val functions just return true.

Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.

NULL and NaN are not quite the same thing imho. If we are allowing NaN
in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar.

Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.

we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
for those three values), else elog().

"non-finite values"

Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.

Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Thomas Lockhart writes:

So, anyone have any ideas what NaN would be useful for? Especially given
we have NULL available, which most (non DB) numeric applications don't.

Hmm. With Tom Lane's new fmgr interface, you *can* return NULL if you
spot a NaN result. Maybe that is the best way to go about it; we'll
stipulate that NaN and NULL are equivalent. And we'll further stipulate
that if you are messing with NaN then you deserve what you get ;)

I beg to differ, this behaviour would not be correct. Instead, this should
happen:

NULL < NULL => NULL
NULL < 1.0 => NULL
NULL < Nan => NULL
1.0 < NULL => NULL
1.0 < NaN => false
NaN < NULL => NULL
NaN < 1.0 => false

Then all the NaN's sort either all first or all last before or after the
NULLs.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

On Sat, 19 Aug 2000, Don Baccus wrote:

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

At 09:01 PM 8/19/00 -0300, The Hermit Hacker wrote:

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

I've e-mailed Ben a "heads-up", though he monitors this list and will probably
see your note.

I'll be gone about five of the next 6-7 weeks mostly doing my annual stint as
a field biologist where I'm only accessible once a day via radio by BLM
Dispatch
in Elko, Nevada so I'm afraid this (like many other things at the moment) will
fall on Ben's shoulders...

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Vince.

On Sat, 19 Aug 2000, The Hermit Hacker wrote:

Ben has an account on Hub, and aolserver has been installed, so if you
guys want to install and get this working, just tell me what else you need
as far as software and/or configurations are concerned and "it shall be
done" ...

On Sat, 19 Aug 2000, Don Baccus wrote:

At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.

It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.

Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

Don Baccus wrote:

(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)

istm that it is *not* that easy. We tried (very briefly) a bug tracking
system. Whatever technical problems it had (which other tools may not),
the fundamental problem is that the mailing lists do a *great* job of
screening problem reports while also supporting and enhancing the
"Postgres culture", whereas a "bug report tool" eliminates that traffic
and requires one or a few people to pay attention to the bug list to
manage new and existing bug reports.

This has (or could have) a *huge* impact on the culture and tradition of
Postgres development, which imho is one of the most satisfying,
pleasant, and effective environments in open source development. So if
we try to do something with a bug tracking system, we will need to
figure out:

o how to retain a free and helpful discussion on the mailing lists, and
to not degrade into a "shut up and check the bug reports" response.

o how to filter or qualify bug reports so that developers don't spend
time having to do that.

All imho of course ;)

- Thomas

At 01:22 AM 8/20/00 +0000, Thomas Lockhart wrote:

istm that it is *not* that easy. We tried (very briefly) a bug tracking
system. Whatever technical problems it had (which other tools may not),
the fundamental problem is that the mailing lists do a *great* job of
screening problem reports while also supporting and enhancing the
"Postgres culture", whereas a "bug report tool" eliminates that traffic
and requires one or a few people to pay attention to the bug list to
manage new and existing bug reports.

In the SDM you can, of course, ask to be notified of various events
by e-mail. And there's a commenting facility so in essence a bug
report or feature request starts a conversation thread.

I don't recall saying that the SDM is simply a "bug report tool". There's
quite a bit more to it, and the goal is to INCREASE interactivity, not
decrease it.

This has (or could have) a *huge* impact on the culture and tradition of
Postgres development, which imho is one of the most satisfying,
pleasant, and effective environments in open source development. So if
we try to do something with a bug tracking system, we will need to
figure out:

o how to retain a free and helpful discussion on the mailing lists, and
to not degrade into a "shut up and check the bug reports" response.

This is a social, not software, engineering issue.

o how to filter or qualify bug reports so that developers don't spend
time having to do that.

Developers don't have to filter or qualify bug reports e-mailed to the
bugs list today? Who's doing it, then, and why can't they continue doing
so if another tool is used to manage bug reports?

The SDM allows a little more granularity than the single e-mail list
aproach allows for. You can designate modules within a package. For
instance, psql might be a module with Peter assigned as an administrator,
and he might elect to get e-mail alerts whenever a bug is submitted to
for psql.

But he might not, for instance, be particularly interested in getting
e-mail alerts on (say) the JDBC driver.

There's a certain amount of delegation inherent in an approach like
this, and developers focused on narrow portions of the product (and
Peter came to mind because of psql, I'm not suggesting he only has
a narrow interest in the product) can arrange to only get nagged, if
you will, for stuff they've taken responsibility for.

My guess is that such a system probably isn't as cozy and useful for
developers, as you're implying.

I think it might well be more friendly for users, though. Certainly
the OpenACS and arsDigita communities - both fairly large though
not as long in the tooth as PG, I might add - seem to appreciate having
access to such a system.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

On Sat, 19 Aug 2000, Don Baccus wrote:

At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:

http://www.postgresql.org/bugs/

I was about to implement it once before and the directory disappeared.
But anyway it's there.

Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)

Like I said, the dir disappeared before I could commit it, probably some
config stuff too. We tried a couple of already in use items and frankly
I got tired of learning a new package that noone used anyway. I figured
at least this one could be more of what we needed. It logs the problem
in the database and emails the bugs list (I may have the wrong list
addr in there too). The status can be changed, entries can be made as
to the status.

What did you do to break it and what broke?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================